Но избегать инноваций — не выход. Платформа, которая не развивается, добавляя новые желанные функции, скорее всего, будет брошена пользователями, нашедшими конкурента, которому есть что предложить. Нужно изыскать способ добиться баланса, изменяя основу платформы медленно и допуская позитивные адаптации на периферии.
Эта концепция сравнима с известной идеей из области вычислительной техники: принципом end‑to‑end. Он был сформулирован в 1981 г. Джерри Зельцером, Дэвидом Ридом и Дэвидом Кларком и гласит, что в неспециализированной сети конкретно ориентированные функции должны относиться к конечным узлам, а не промежуточным[35]. Иными словами, действия, не являющиеся базовыми для работы сети и ценные только для отдельных пользователей, должны находиться на краях платформы, а не в ее сердцевине. Тогда вторичные функции не будут смешиваться, оттягивать ресурсы от основных действий в сети или усложнять задачу поддержки либо обновления сети в целом. Со временем принцип end‑to‑end был перенесен с устройства сетей на устройство многих других сложных вычислительных сред.
Один из самых громких примеров неудач в применении принципа end‑to‑end — запуск в 2007 г. Windows Vista, последней операционной системы Microsoft с «окнами». Директор Стивен Балмер объявил, что Vista — «величайший запуск в истории Microsoft», и выделил маркетинговый бюджет в сотни миллионов долларов[36].
Но Vista не оправдала себя. Команда разработчиков Microsoft попыталась сохранить программные компоненты, необходимые для поддержки совместимости со старыми компьютерными системами, одновременно добавляя функции, необходимые для систем нового поколения — причем в ядре платформы. В результате Vista получилась менее стабильной и более сложной, чем ее предшественница Windows XP, и сторонним разработчикам приложений с трудом удавалось писать для нее код[37].
Критики писали, что Vista — даже не фуфлософт, а «козлософт», потому что она пожирала все ресурсы системы[38]. Миллионы пользователей Windows отказались использовать Vista и до сих пор крепко держатся за Windows XP, несмотря на многочисленные попытки Microsoft отправить ее на пенсию. Ирония судьбы: Microsoft прекратила розничные продажи XP в 2008 г. и Vista в 2010 г., но рыночная доля XP в 2015 г. была выше 12 %, а рыночная доля Vista — ниже 2 %[39].
Стив Джобс, вернувшийся к руководству Apple в 1997 г. после нескольких лет разработки амбициозного, но неудачного компьютера NeXT, принял крайне важное решение, которое отвечало принципу end‑to‑end и помогло привести Apple к успеху. В NeXT Джобс и его команда разработали элегантную новую операционную систему с чистой, многослойной архитектурой и прекрасным графическим интерфейсом. В итоге, выбирая наследника операционной системы Apple Mac OS 9, Джобс встал перед сложным выбором: он мог смешать программные коды NeXT и Mac OS 9, создав операционную систему, которая будет совместима с обеими, или отказаться от Mac OS 9 в пользу архитектуры NeXT.
Джобс рискнул отказаться от старого кода OS 9, но пошел на одну уступку: команда разработчиков создала отдельное «Классическое окружение», которое позволяло пользователям запускать старые приложения из OS 9. Этот индивидуализированный подход отвечал принципу end‑to‑end. Старый код не замедлял и не усложнял новые приложения, и новые покупатели Mac не были перегружены программами, поддерживающими приложения, которыми они не пользовались. Выбор Джобса сделал инновации в новом Mac OS X более простыми и эффективными, что позволило Apple развить новые функции. В сравнении с ней системы Microsoft выглядят устаревшими[40].
Концепцию end‑to‑end можно применить и к разработке платформ. Здесь принцип таков: специализированные функции должны оказываться на периферии или на поверхности платформы. Только крупномасштабные, ценные функции, которые затрагивают все приложения, должны стать частью сердца платформы.
Соблюдать это правило стоит в силу двух причин. Во‑первых, когда специфические новые функции включаются в ядро платформы, вместо того чтобы «крепиться» на периферии, приложения, которые не пользуются этими функциями, будут работать медленно и неэффективно. Если же функции запускаются через приложение, а не ядром платформы, пользователи получают куда более приятные впечатления.
Во‑вторых, экосистема платформы может развиваться быстрее, когда ядро платформы — чистая, простая система, а не клубок бесчисленных функций. Поэтому Карлисс Болдуин и Ким Кларк из Гарвардской бизнес‑школы описывают грамотную платформу как состоящую из двух уровней: стабильное ядро, которое ограничивает вариативность и лежит в основе постоянно развивающегося уровня, допускающего вариации[41].
Этот принцип сегодня применяют самые качественные платформы. Например, Amazon Web Services (AWS), наиболее успешный поставщик облачных систем хранения и управления данными, сосредоточена на оптимизации нескольких базовых операций, включая хранение данных, вычисления и обмен сообщениями[42]. Другие услуги, которые использует только часть клиентов AWS, ограничены периферией платформы и доступны через специальные приложения.
Власть модулярности
В интегральном подходе, когда система развивается максимально быстро, чтобы служить единственной цели, особенно в первые дни ее существования, есть свои преимущества. Но в долгосрочной перспективе успешная платформа должна обратиться к модулярному подходу. Полное рассмотрение этого принципа выходит за рамки данной главы, но мы затронем некоторые важные идеи. Начнем с определения, данного Болдуин и Кларком (1996 г.).
Модулярность — стратегия эффективной организации сложных продуктов и процессов. Модульная система состоит из единиц (или модулей), разработанных независимо, но действующих как единое целое. Разработчики достигают модулярности, дробя информацию на видимые технологические стандарты и скрытые параметры. Модулярность выгодна, только если деление точно, недвусмысленно и полно. Видимые технологические стандарты (видимая информация) — решения, которые влияют на дальнейшую разработку. В идеале они закладываются в начале процесса и доводятся до сведения тех, кто в нем участвует[43].
В статье 2008 г. Карлисс Болдуин и Джейсон Вударт предложили полезное и емкое определение стабильного ядра системы.
Мы утверждаем, что фундаментальная архитектура, лежащая в основе всех платформ, по существу одна и та же: система разделена на набор «ядерных» компонентов с низкой вариативностью и дополнительный набор «периферальных», высоковариативных. Низковариативные компоненты составляют платформу. Это долгоживущие элементы системы, которые таким образом скрыто или явно определяют интерфейс системы и правила, управляющие взаимодействиями между разными участниками[44].
Почему же модулярность эффективна? Потому что, когда системы явно поделены на подсистемы, они могут работать и как целое, объединяясь и взаимодействуя через четко прописанные интерфейсы. Следовательно, подсистемы могут разрабатываться индивидуально, если подчиняются общим стандартам разработки и совместимы с остальной системой с помощью одного стандартного интерфейса. Вы, наверное, встречали термин «программный интерфейс приложений» (Application Programming Interface, API). Это стандартные интерфейсы таких систем, как Google Maps, New York Stock Exchange, Salesforce, Thomson Reuters Eikon, Twitter и многих других, используемые для облегчения доступа внешних участников к корневым ресурсам[45].
