WTF? Гид по бизнес-моделям будущего

В целях исследования рынка компания O’Reilly делала запрос по Amazon через глобальный поиск по сети каждые три часа, чтобы загружать информацию о ценах, рейтинге, количестве страниц и рецензиях на наши книги и книги наших конкурентов. Глобальный поиск по сети казался мне нерациональным, поскольку нам приходилось загружать гораздо больше данных, чем требовалось, а затем извлекать только нужные биты информации. Я был убежден, что огромный каталог товаров Amazon был прекрасным примером обширного набора данных, к которому следует предоставить доступ – в программном отношении через веб-сервисы API в «операционной системе Интернета» следующего поколения, которую я проповедовал.

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

Я как сейчас помню разочарование Джеффа по поводу моей речи на этой внутренней конференции разработчиков Amazon. Когда я закончил, он вскочил с задних рядов зала и сказал: «Вы не сказали ни слова о том, что платформа всегда одерживает победу над приложением!» Но я не ошибся, когда произнес другую версию своей речи на всеобщем собрании Amazon в мае 2003 года.

Веб-службы первого поколения, внедренные гигантом электронной коммерции в 2003 году, были связаны с доступом к их внутреннему каталогу товаров и к его базовым данным и имели мало общего с инфраструктурными услугами, которые были запущены под названием «Веб-сервисы Amazon» (или AWS) в 2006 году и стали отправной точкой великих преобразований в отрасли. Теперь это называется «облачной обработкой данных». Эти службы возникли по совершенно разным причинам, но мне нравится думать, что именно я заронил Джеффу идею о том, что для процветания компании Amazon в ближайшие годы необходимо стать чем-то гораздо большим, чем просто приложение электронной коммерции. Она должна была стать платформой.

Благодаря своей великолепной стратегии принимать любую идею и как следует ее обдумывать, Джефф продвинул идею платформы намного дальше, чем я себе представлял. Как поведал Джефф в коротком интервью Ому Малику в 2008 году: «Когда все это началось четыре года назад, у нас было довольно много сложностей внутри компании Amazon. Мы поняли, что тратим слишком много времени на точечную координацию действий между нашими группами сетевой технологии и группами прикладного программирования. По сути, то, что мы решили сделать, – это создать набор API-интерфейсов между этими двумя уровнями, чтобы можно было выполнять более общую координацию между этими двумя группами» (то есть это были «свободно соединенные мелкие частички»).

Что важно: веб-службы компании Amazon были созданы как решение проблемы организационной структуры. Джефф понял то, что должен понять каждый сетевой бизнесмен XXI века. Это то, что однажды сказал мне HR-эксперт Джош Берсин: «Производить цифровые технологии – это не то же самое, что быть цифровыми технологиями».

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

То, как Джефф перенес представление об Amazon как о платформе из сферы программного обеспечения в организационную структуру, нужно преподавать в каждой бизнес-школе. Об этом рассказал бывший инженер Amazon Стив Йегге в статье, написанной для своих коллег из Google, которая была случайно обнародована и стала вирусной среди интернет-разработчиков. Она известна как «Тирада Стива о платформе». В ней Йегге ссылается на записку, которую, как он утверждает, Джефф Безос написал «примерно в 2002 году, я думаю, плюс-минус год»:

«Его «Большой приказ» был изложен примерно в таком духе:

1. Отныне все команды будут обнародовать свои данные и функциональные возможности через служебные интерфейсы.

2. Команды должны общаться друг с другом через эти интерфейсы.

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

4. Не имеет значения, какую технологию они используют. HTTP, Corba, Pubsub, собственные протоколы – не важно. Безосу нет до этого дела.

5. Все служебные интерфейсы, без исключения, должны быть разработаны с нуля, чтобы впоследствии стать внешними. Иными словами, команда должна вести планирование и разработку таким образом, чтобы иметь возможность предоставить интерфейс разработчикам во внешнем мире. Без исключений. Любой, кто этого не сделает, будет уволен».