Архитектура взаимодействия

Некоторые системы спроектированы для усиления взаимодействия. Существует три способа создания большой БД. Первый - платить людям за ее составление (Yahoo!). Второй - набрать для той же задачи добровольцев (open-source-проекты). Третий путь открыл Napster. В клиенте Napster по умолчанию загруженная песня была доступна для скачивания другими пользователями сети. Таким образом, каждый пользователь Napster увеличивал ценность распределенной БД. Потом эта же схема была повторена в других P2P-сервисах.

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

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

Другими словами, эти технологии демонстрируют сетевые эффекты, просто потому, что они так спроектированы.

Такую архитектуру взаимодействия можно назвать естественной. Но как показал пример Amazon, последовательные усилия (а равно и экономические стимулы - например, партнерская программа) могут создать подобную архитектуру и в системе, которой при обычных условиях это не свойственно.

Конец цикла разработки по

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

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

Также не случайно, что скриптовые языки - Perl, Python, PHP, а теперь еще и Ruby - играют в жизни компаний Веба 2.0 столь важную роль. Первый вебмастер Sun Microsystems Хасан Шрёдер (Hassan Schroeder) как-то назвал Perl "скотчем интернета".

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

Пользователей нужно воспринимать как соразработчиков - как, например, принято при разработке открытого софта (даже если само ПО вряд ли будет выпущено под открытой лицензией). Максима открытого софта - "выпускай релизы раньше и чаще" - теперь формулируется еще жестче: "бесконечная бета-версия". Программы обновляются ежемесячно, еженедельно и даже ежедневно.

Не случайно на логотипах таких проектов, как Gmail, Google Maps, Flickr, del.icio.us и т. п., словечко "beta" может висеть годами.

Отслеживание поведения пользователей в реальном времени позволяет видеть, какие новые свойства используются и как они используются - и это еще одна ключевая составляющая успеха технологии. Веб-разработчик одного из раскрученных сетевых сервисов отмечает: "мы добавляем два-три новых свойства в разные части сайта каждый день, и если пользователям они не нравятся - мы отказываемся от этих нововведений. Если нравятся - внедряем на всем сайте".

Кэл Хендерсон (Cal Henderson), главный разработчик Flickr, недавно рассказал, что новый билд Flickr появляется каждые полчаса. Это совершенно другая модель разработки! И хотя пока не все веб-приложения разрабатываются с такой экстремальной скоростью, почти у всех цикл разработки радикально отличается от всего, что было в эпоху ПК или клиент-серверов. По этой причине редакторы Zdnet даже пришли к выводу, что Microsoft не удастся победить Google: "бизнес-модель Microsoft построена на предположении, что пользователь обновляет свое компьютерное окружение раз в два или три года. Google же зависит от того, что новенького обнаружит пользователь в своем компьютерном окружении сегодня".

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