Войти в систему
Войти с помощью соц. сетей:
Важно не то, как вы используете серверы, а то, как вы обслуживаете клиентов.
Как уже отмечалось в главе 1, по моему убеждению, каждая компания, которая хочет выжить и добиться успеха в цифровой экономике, должна создавать программное обеспечение. Иными словами, многое зависит от вашей цепочки поставок ПО. Если ваша цифровая цепочка поставок лучше, чем у конкурентов, у вас будет гораздо больше шансов на успех. И наоборот, если ваша цепочка поставок неэффективна или устарела, а конкуренты захватывают лидерство, то вы всегда будете плестись в хвосте. Предположу, что вопрос о цифровой цепочке поставок не стоит на первом месте в вашей компании — это совершенно новая концепция. Но осознание крайней необходимости цифровой цепочки поставок и представление о том, как использовать ее для обеспечения лидерства, имеют решающее значение для успеха в цифровой экономике.
Представьте себе отрасли, производящие физические товары, например автомобили, холодильники или строительные материалы. Все они имеют развитые цепочки поставок. Автопроизводители не создают каждый компонент автомобиля сами. Они покупают сталь у сталелитейной компании, кожу — у компании по выделке кожи, сиденья — у их производителя, спидометры — у приборостроительной компании и т.д. Все эти автомобили Camry и пикапы F-150, проносящиеся мимо вас по шоссе, собраны из частей, поставляемых сотнями, а может, и тысячами крупных поставщиков. Эти поставщики, в свою очередь, привлекают сотни или даже тысячи мелких производителей деталей по всей глобальной цепочке поставок. По мере созревания отраслей развиваются и их цепочки поставок, что позволяет многим компаниям специализироваться на отдельных частях процесса, обеспечивая общую эффективность и продуктивность.
До недавнего времени в софтверной индустрии такого не было. Большинство софтверных компаний — взять хотя бы Microsoft, Oracle или SAP — самостоятельно написали свои программы от начала до конца. Это работало, когда программное обеспечение было узкоспециализированной областью и на рынке присутствовало относительно мало софтверных компаний, т.е. вплоть до 1990-х и начала 2000-х гг. Это было особенно очевидно, когда разработчики продавали свои продукты в виде загружаемых файлов или на CD-ROM.
Сейчас все компании становятся софтверными, но большинство из них не могут строить все с нуля. Им нужна цепочка поставок — точно так же, как автомобильным компаниям Ford и Toyota, — которая делит отрасль на специализированные области и позволяет каждой компании в экосистеме делать то, что она умеет лучше всего. Однако цепочка поставок программного обеспечения выглядит иначе. В ней компании вместо специализации на спидометрах или рулевых колесах поставляют универсальные части программного кода, которые разработчики объединяют в готовые приложения. Это интерфейсы прикладного программирования (API). Каждый поставщик API предоставляет только часть программного решения. Например, Amazon Web Services предлагает дата-центр, Twilio обеспечивает связь, а Stripe и PayPal позволяют осуществлять платежи. Современные приложения интегрируют десятки этих небольших компонентов в уникальное ценностное предложение для клиента. Такой переход к компонентному программному обеспечению является большим скачком в эволюции софтверной индустрии.
Я называю это третьей эрой программного обеспечения.
Эту тенденцию — переход от готовых решений к строительным блокам — лучше всего предсказал рекламный ролик компании IBM 1990-х гг. Взлохмаченный консультант показывает владельцу бизнеса первый вариант сайта, который, похоже, был сделан без особого участия владельца. Консультант заканчивает свою речь словами: «Теперь у вас есть выбор… между вращающимся логотипом или пылающим». В верхнем левом углу сайта (где в те дни всегда стоял логотип) красуется логотип компании, то глупо вращающийся по кругу, то подсвечиваемый языками пламени. Озадаченный бизнесмен отвечает: «Хорошо, но может ли это оптимизировать мою цепочку поставок?» Идея заключалась в том, что готовое программное обеспечение, обладающее лишь номинальной гибкостью, никогда не удовлетворит потребности быстро развивающегося, сложного бизнеса. Теперь, более чем 20 лет спустя, этот рекламный ролик оказался невероятно пророческим. Но, как это часто бывает, вовсе не компании-старожилы сделали эту идею реальностью.
Чтобы понять новый подход к программному обеспечению, нужно вспомнить, как возникла софтверная индустрия и как она развивалась.
Сначала компании работали на мейнфреймах. Многие это делают до сих пор, причем гораздо чаще, чем можно представить. Затем появились мини-компьютеры, рабочие станции Unix и, наконец, персональные компьютеры. Те, кому меньше 30 лет, могут не помнить этого, но, когда появился персональный компьютер, программы в буквальном смысле поставлялись на гибких дисках, а позднее — на CD. Программное обеспечение на самом деле везли в коробках! Вы приходили в магазин типа Babbage’s, Egghead Software или Software Etc и брали программы с полки. Серьезно, эти магазины были просто замечательны.
В процессе эволюции компьютеры становились все меньше, их операционные системы менялись, но софтверная индустрия использовала все ту же бизнес-модель. Производитель программного обеспечения инвестирует деньги в исследования и разработки, создает программу, а затем продает ее индивидуальным пользователям или крупным предприятиям. Продажа ПО потребителям была хорошим бизнесом, а продажа его предприятиям, как это делали Microsoft, SAP и Oracle, просто великолепным. С точки зрения прибыльности продажа готового программного обеспечения крупным компаниям могла стать величайшим бизнесом в истории: вы однократно создаете программу и практически не несете приростных издержек при ее продаже.
Но для бизнес-клиентов такая схема была изрядной головной болью. Каждая компания должна была иметь собственный ИТ-отдел, который занимался обеспечением работы серверов, установкой ПО и обслуживанием всей компьютерной инфраструктуры. Большинство программ были предназначены для выполнения внутриофисных задач, таких как управление финансами и ресурсами предприятия. Подобные крупные корпоративные программные проекты редко заканчивались успешно — одно время более 70% из них оставались незавершенными. Реализация этих проектов занимала так много времени, что зачастую сменялось несколько поколений руководителей компаний, прежде чем их доводили до конца.
Важно отметить, что компании использовали это ПО не для того, чтобы лучше обслуживать клиентов или выделяться на рынке. Оно было нужно для выполнения внутренних задач — бухгалтерского учета, управления ресурсами предприятия и т.п. И если вы отвечали за самостоятельное направление деятельности внутри компании, например были руководителем отдела продаж или отдела кадров, и вам требовалось программное обеспечение для управления отделом, то вам приходилось направлять заявку в ИТ-отдел и ждать своей очереди.
Эта проблема была решена с наступлением второй эры программного обеспечения — с предоставления программного обеспечения как услуги (SaaS — Software as a Service). Это произошло около 20 лет назад. Компанией, которая первой применила эту модель, была Salesforce. Ее основатель и генеральный директор Марк Бениофф стажировался в качестве программиста ассемблера в Apple (т.е. был программистом высшего класса), а после университета пришел в компанию Oracle, где быстро стал весьма успешным менеджером по продажам.
Он получил номинацию «Новичок года» в компании и дорос до вице-президента, когда ему было около 25 лет — самый молодой вице-президент в истории Oracle. В 1999 г. он запустил компанию Salesforce под лозунгом «Конец программного обеспечения». Конечно, на самом деле речь шла не о конце программного обеспечения, а о новом способе его поставки.
При использовании модели SaaS руководителям направления деятельности, нуждавшимся в новом ПО, не нужно было посылать заявку в свой ИТ-отдел, а затем стоять в очереди и ждать, пока там возьмутся за огромное многомиллионное и многолетнее дело. Вместо этого руководитель отдела продаж мог просто зайти на сайт Salesforce, заполнить несколько онлайн-форм и почти мгновенно подключить весь отдел к лучшей в своем классе программе по автоматизации продаж. Руководителю отдела продаж не нужно было обладать познаниями в ИТ-сфере, закупать серверы, устанавливать программное обеспечение или нанимать ИТ-персонал для обслуживания системы. Требовалось просто заполнить анкету, и все.
Со временем SaaS-компании начали обслуживать руководителей всех направлений деятельности в компаниях. Так, финансовый директор (CFO) обращался к компании NetSuite, поставщику финансового ПО. Руководитель отдела маркетинга был подписан на сервис компании Marketo — SaaS-поставщика средств автоматизации маркетинга. Директор по персоналу пользовался сервисом компании Workday. Плата этим компаниям зависела от количества сотрудников, использовавших соответствующее ПО. Больше не нужно было беспокоиться о дата-центрах или лицензиях. На деле многие программные продукты были настолько недорогими, что небольшая команда могла просто оплатить их покупку кредитной картой.
Эту модель также называют облачными вычислениями, которые стали возможными благодаря высокоскоростному интернет-подключению и так называемому многопользовательскому программному обеспечению. С появлением сверхбыстрых интернет-магистралей люди поняли, что можно передавать биты с сервера, расположенного за тысячи миль, так же быстро, как и с сервера в коридоре или с другой стороны двора в собственном дата-центре компании. (Во всяком случае разница настолько мала, что пользователи программы не замечают ее.) При облачных вычислениях больше не требовались собственные дата-центры. И сотрудникам не нужно было запускать локальные версии программ на своих компьютерах. Они просто делали все необходимое через веб-браузер. Это облегчало жизнь во всех отношениях. Если программа имела ошибку и нуждалась в обновлении или если поставщик программного обеспечения выпускал обновление, клиентам не нужно было посылать ИТ-специалистов к каждому рабочему месту и устанавливать новую версию программы. Эти исправления и обновления просто происходили в облаке. Для пользователя все оставалось невидимым.
Изменение коснулось и бизнес-модели. Вместо того чтобы платить за лицензии на программы в зависимости от количества серверов, включая первоначальный взнос, а затем ежегодную плату за обслуживание, вы просто подписывались на ПО. Когда потребность в программном обеспечении отпадала, подписку просто отменяли — примерно так же, как подписку на журнал.
Когда в 1999 г. компания Salesforce только начинала свою деятельность, многие считали Бениоффа сумасшедшим. Зачем кому-то платить за программное обеспечение, которое ему не принадлежит? Что произойдет, если отключится интернет? Не забывайте, что в те времена интернет не был достаточно быстрым и надежным для SaaS-модели: к 2001 г. только 6% американцев имели широкополосный доступ к интернету. По данным Исследовательского центра Пью, в те времена подавляющее большинство пользователей выходило в интернет через коммутируемое соединение с пищащими модемами.
Но Бениофф знал, что интернет со временем будет лучше и надежнее. Когда высокоскоростной интернет стал нормой, Salesforce превратилась в одну из крупнейших софтверных компаний в мире, с доходом $17 млрд в 2020 финансовом году. И Salesforce не одинока — за годы, прошедшие с начала тысячелетия, возникло множество многомиллиардных SaaS-компаний.
Но как бы ни были хороши SaaS-поставщики, самая быстрорастущая софтверная компания в мировой истории не имела ничего общего с Salesforce или Workday.
Я пришел на работу в компанию Amazon в 2004 г., когда облачная платформа Amazon Web Services (AWS) только появилась. Мой босс сразу же объяснил мне мою миссию. Amazon собиралась строить огромные дата-центры и сдавать в аренду вычислительные мощности не в форме приложений, а в виде строительных блоков, которые разработчики и другие компании могут использовать для создания собственных приложений. Это позволило бы любому разработчику и любой компании использовать все возможности сетевой инфраструктуры Amazon. Сервис должен быть гибким, обеспечивающим мгновенное наращивание и сокращение масштабов. Если ваш трафик резко возрастает и держится на высоком уровне несколько дней, то «эластичное вычислительное облако» просто предоставляет дополнительную компьютерную мощность вашему сайту. Когда всплеск трафика заканчивается, ваш виртуальный дата-центр уменьшается. Вы платите только за те ресурсы, что использовали. Вам выставляют ежемесячный счет аналогично счету за мобильный телефон и электричество.
Модель платы в зависимости от фактического пользования сервисов была огромным прорывом, возможно, не менее значительным, чем сама технология. Старая модель предварительной покупки аппаратных средств («железа») была абсурдно дорогой и чудовищно неэкономной. Десятилетиями компании покупали гораздо больше мощностей, чем им было нужно, и набрали массу избыточного оборудования. Процессоры стояли без дела. Накопители данных пустовали. Уровень использования дисковых систем хранения данных временами не превышал 30%. Серверы обычно загружались на 10%. Каждое приложение нуждалось в собственных выделенных серверах и хранилищах данных — достаточных, чтобы справиться с максимально возможной нагрузкой.
Ресурсы, предназначенные для работы с одним приложением, зачастую не могли использоваться для других. Системе расчетных терминалов могли требоваться дополнительные мощности во время напряженного курортного сезона, но у нее не было возможности воспользоваться ресурсами незагруженной системы службы по работе с персоналом, расположенной рядом с ней. Приходилось приобретать избыточные мощности, чтобы покрыть пиковую нагрузку в отпускной период, даже если в остальное время они были не нужны. Разработчики создали программы, которые позволяли ИТ-системам использовать общие ресурсы, но такое решение означало появление еще одной дорогостоящей программы и еще одной команды ИТ-специалистов. Устранение одной головной боли создавало другую. Переход на платформу AWS устранял потребность не только в покупке дорогого «железа», но и в создании огромного ИТ-отдела, работающего в круглосуточном режиме семь дней в неделю. Это было еще одно огромное снижение затрат.
Создав платформу AWS, компания Amazon словно по мановению волшебной палочки устранила причины этой головной боли. Оформите подписку и забудьте о необходимости содержать аппаратные средства и хранилище данных — просто платите за то, что вы фактически используете.
Разница между этой моделью и моделью первой эры программного обеспечения была такой же, как разница между производством электроэнергии с помощью собственного дизельного генератора и покупкой электроэнергии у обслуживающей компании. Вы понятия не имеете, где работают ваши программы и на каком компьютере. Да это и не важно — все происходит в облаке (на заре существования облачных технологий это были чаще всего серверы в Вирджинии). Заботу обо всем этом берет на себя кто-то другой. Единственное, что вас волнует, — это появление в вашем распоряжении дата-центра по щелчку переключателя, причем такого размера, который необходим. Крупные компании ухватились за это решение. Они начали переносить приложения из собственных дата-центров в облако Amazon.
Другие последствия появления платформы AWS были не так очевидны. Прежде всего работа с ней снижала стоимость запуска новой компании почти до нуля. Раньше, когда вы создавали высокотехнологичную компанию, нужно было покупать дорогие серверы, системы хранения данных, маршрутизаторы и системы управления базами данных. На реализацию первой версии идеи могло уйти до миллиона долларов.
С платформой AWS и ее моделью платы за фактическое использование ресурсов предпринимателю достаточно около сотни долларов и нескольких минут, чтобы заполнить форму на сайте и ввести номер кредитной карты. В результате низкой стоимости запуска стало появляться намного больше стартапов. Стартапы также получили возможность быстрее выходить на рынок. Они могут перейти от идеи, набросанной на салфетке (или в случае Twilio на обратной стороне коробки от пиццы), к отгрузке продукта в течение нескольких месяцев. Они могут расширяться и расти без проблем с инфраструктурой, быстрее эволюционировать и создавать новые продукты.
Во время работы в AWS я понял, что эта платформа должна дать начало новому поколению стартапов, которые будут несравнимо быстрее и эффективнее традиционных компаний. Эти проворные маленькие хищники начнут революционизировать компании во всех отраслях, а их крупные конкуренты станут создавать новое ПО, еще более ускоряя темпы обновления отрасли.
Но для меня самым интересным последствием внедрения AWS стало изменение не только способа покупки вычислительной мощности, но и сообщества ее покупателей. В традиционном мире ИТ-решения принимались людьми, близкими к верхушке организации, — директором по информационным технологиям или финансовым директором. Причина проста — это были решения с высокими ставками, связанные с годами работы и вложением миллионов долларов. У AWS значительную долю клиентов составляли обычные разработчики. Конечно, инженеры или руководители отделов тоже могут арендовать сервер и хранилище данных на AWS, просто введя номер кредитной карты. Когда компания начинает пользоваться приложением на AWS, ИТ-отдел не переносит код в собственный дата-центр — он оставляет его в облаке. По мере расширения его использования растет размер месячного счета. А раз так, то разработчики получают гораздо больше влияния на процесс покупки компаниями инфраструктуры.
Эти тенденции отражаются в бизнес-результатах AWS. Ее продажи выросли практически с нуля в 2007 г. до $40 млрд в год по состоянию на первый квартал 2020 г. От нуля до $40 млрд за 12 лет — поистине беспрецедентный рост. Вот почему эта бизнес-модель — модель платформенного бизнеса — является знаковым моментом в софтверной индустрии.
Но Amazon не единственный двигатель третьей эры программного обеспечения. Microsoft, Google и Alibaba создали свои конкурирующие облачные платформы, предлагающие вычислительные ресурсы, хранилища и многое другое, что могут интегрировать разработчики сервисов. Выручка Microsoft Azure в 2019 г. составила $37 млрд, а Google Cloud — $9 млрд. Это гиганты в своей области. Моя компания Twilio предоставляет API для коммуникаций и быстро растет — в 2019 г. ее доход составил $1,1 млрд. Частная компания Stripe, предоставляющая платежные API, не раскрывает объем своих продаж, но частные инвесторы оценили ее в $36 млрд по состоянию на апрель 2020 г. Третья эра программного обеспечения дает очень много не только клиентам, но и инвесторам.
Еще более интересной, нежели сама «экономика API», появившаяся в последнее десятилетие, является история ее возникновения. Ведь неочевидно, как масса крошечных API, использование каждого из которых обходится в центы, приносит десятки миллиардов долларов дохода и позволяет запускать те приложения, которыми мы все пользуемся ежедневно. История происхождения API тесно связана со многими другими аспектами софтверной индустрии, которые я подробно описываю в этой книге. Все началось с небольших команд.
В 2000 г. в компании Amazon царил полный кавардак во всем, что касалось разработчиков и кодов, поддерживающих быстрорастущий розничный бизнес. Разработчики соперничали друг с другом, и координация их действий для получения результата требовала огромных усилий. Рабочий процесс замедлялся, и тогда Безос придумал «правило двух пицц», которое предполагало создание небольших команд, чтобы работа шла быстрее. (В соответствии с его идеей команде должно было хватать двух пицц, чтобы перекусить.) Но все было не так просто.
Как организовать в компании небольшие независимые команды, когда работа замыкается на общий код, который они пишут? Они не могут по-настоящему работать независимо, если изменения, внесенные одной командой, нарушают код, который создали другие команды. Такой продукт просто не будет работать.
Ответом стало сохранение и кода, и команд как единого целого. Поскольку Amazon разделила организацию на небольшие команды, она продолжила делить код на мелкие части, чтобы команды могли «брать их» и работать независимо. Но команды нуждались в общении друг с другом и обмене результатами работы. Решением стали «веб-сервисы». Вместо того чтобы отправлять код в гигантское хранилище, который кто-то организует и поддерживает на серверах, команды запускали свои коды как сервисы, с которыми другие команды могли взаимодействовать. Со временем их стали называть «микросервисы», поскольку каждый из них обычно выполнял одну функцию, но делал это хорошо.
Микросервисы поставлялись не как часть кода, не как сайт, а как онлайновые API. API — это четко определенные интерфейсы, которые позволяют коду общаться с другими частями кода. Когда команда создает и предоставляет API другим, важно, чтобы она научила других пользоваться им с помощью точной и актуальной документации. Таким образом, в Amazon сформировалась внутренняя культура API-документации. Одна команда могла найти API-документацию другой команды и пользоваться ее сервисами нередко даже без прямого общения. Это позволило командам эффективно работать вместе и решить проблему координации.
Следующая проблема заключалась в оценке эффективности каждого из этих сервисов и учете того, куда уходят деньги. Если одна команда запустила свой сервис на 10 000 серверов, это хорошо или ужасно неэффективно? И на какую бизнес-цель следует относить затраты? Поэтому Amazon начала списывать затраты на использование этих сервисов даже внутри компании. Некоторые называют это трансфертным ценообразованием, но фактически такая система решает две задачи: делает команды ответственными за свои расходы и помогает принимать решения о том, на что закладывать больше средств в бюджетах.
Небольшие команды отвечают за эффективность своих сервисов, поскольку они по существу называют «цену» для внутренних клиентов, а последним приходится покрывать затраты из своих средств. Если эти «клиенты» недовольны вашей ценой, значит, вам есть над чем работать. Внутренняя система учета согласовывает интересы всех сторон и создает естественный стимул для повышения эффективности с течением времени. Внутреннее ценообразование также позволяет лидерам принимать правильные бюджетные решения. Представьте, что у вас есть два клиентских продукта, один из них приносит доход $100 млн и быстро растет, а другой — $10 млн и растет медленно. На какой из них вы выделите больший бюджет? Ответ очевиден, когда у вас есть показатель в виде дохода. То же самое касается и внутренних сервисов. Когда сервис широко используется внутренними клиентами и быстро растет, вы должны выделять на него больше средств. Но без показателя, позволяющего сравнивать инициативы, трудно сказать, какие команды нуждаются в дополнительных инвестициях. Вот почему введение цены даже для внутренних клиентов чрезвычайно полезно.
Но здесь все становится еще интереснее. После того, как вы разделили коллектив на небольшие команды, специализирующиеся на определенных областях и предлагающие друг другу микросервисы с хорошо документированными интерфейсами и ценами, которые отражают истинную стоимость этих сервисов, возникнет вопрос: зачем разрабатывать все эти микросервисы внутри компании? Зачем загружать собственных разработчиков созданием микросервисов, которые можно купить у других компаний? Зачем создавать свой микросервис для пересчета валют при международной торговле, когда можно просто купить этот микросервис у поставщика, специализирующегося на программном обеспечении для подобных операций? Итак, ваши разработчики начинают использовать продукты специализированных поставщиков, и у вас появляется цепочка поставок программного обеспечения. Есть ли разница в том, какой логотип красуется на визитных карточках этих поставщиков микросервисов?
Вскоре стало понятно, что можно делать бизнес на создании микросервисов и их продаже другим. Компания New Relic, основанная в 2008 г., выпустила программу, которая отслеживает результаты работы сайта. Компания Stripe создала платежные сервисы. Компания Twilio разработала облачную коммуникационную платформу. Еще один пример — Google Maps. С помощью всего лишь нескольких строк кода разработчики могут встроить этот сервис в свой сайт. Это намного лучше, чем самостоятельно запускать автомобили с камерами на крыше на улицы городов мира, а затем создавать карты с аэрофотоснимками, видами улиц и всеми другими функциями, которые уже имеются у Google Maps. Ценностное предложение здесь довольно очевидно.
Каждый из нас брал проблему, которую было действительно трудно решить, тратил несколько лет на разработку решения и теперь предоставляет свой сервис другим. Наш сервис — это черный ящик. Клиенты не знают, как он работает, да их это и не волнует. Они просто берут наш код, пишут небольшую программу и запускают приложение. В общей сложности Twilio сейчас предоставляет более тысячи микросервисов. Мы продаем их на условиях оплаты фактического использования точно так же, как Amazon продает свои вычислительные мощности.
Облачные платформы — это новые строительные блоки для современных разработчиков. Они намного ускорили и удешевили создание приложений, их можно масштабировать для поддержки миллиардов пользователей. Все это было невозможно представить еще десятилетие назад.
Третья великая эра программного обеспечения приносит не только множество выгод, но и ставит новый набор вопросов, требующих ответа. Разработчикам и руководству компаний приходится все время решать, какие микросервисы купить у поставщиков облачных сервисов, а какие создать самим. Тому, кто принимает решения, необходимо быть в курсе взрывного роста числа выходящих на рынок новых поставщиков микросервисов. При этом идет непрерывный процесс изменения и совершенствования микросервисов.
«Высокотехнологичные компании постоянно обсуждают, какие микросервисы создавать, а какие покупать, — говорит Эштон Катчер, инвестировавший в десятки стартапов и записавший на свой счет несколько крупных коммерческих побед, в первую очередь сервисы Airbnb, Spotify и Uber. — Полагаю, что та часть ПО, которую вы не создаете, так же важна, как и часть, создаваемая самостоятельно. Единственное, что компании должны неизменно создавать сами, так это ключевые элементы их бизнеса. Люди очень часто занимаются созданием того, что уже существует в виде продукта, который можно сравнительно дешево купить или использовать по лицензии. Нужно ли создать собственную систему учета трудозатрат и начисления заработной платы? Я бы никогда не попытался перестраивать компании Twilio, Slack или Gusto».
Лично я считаю, что нужно создавать самостоятельно все, что дифференцирует вас при работе с клиентами. Иными словами, вы должны создавать ПО, с которым взаимодействуют ваши клиенты, чтобы не возникла ситуация, когда они спрашивают, почему программа не делает того-то и того-то, а вам приходится отвечать, что все дело в купленном ПО. Все, что затрагивает интересы клиентов, нужно делать своими руками. Случается, что есть смысл написать собственную серверную часть ПО. Иногда в бизнесе конкурентное преимущество дает хорошее управление запасами. Безусловно, в таком случае нужно создавать собственную цепочку поставок ПО.
Но для большинства серверных операций и всего, что не обеспечивает дифференциации при работе с клиентами, ПО необходимо покупать. Вы же не собираетесь создавать собственную электронную почту или систему управления базами данных? Системы управления кадрами, ERP-системы — это области, где вы, скорее всего, не получите конкурентного преимущества в результате собственных разработок. Поэтому хорошим решением будет покупка приложения у SaaS-поставщика. Но позвольте мне еще раз повторить правило: все ПО, с которым взаимодействует клиент, необходимо создавать самостоятельно.
Дифференциацию невозможно купить. Ее можно лишь создать самостоятельно.
Но есть и хорошие новости: создавать ПО стало намного проще. Когда-то, до появления зрелой цепочки поставок ПО, выходом обычно была покупка готовых решений, поскольку решиться на создание собственных было слишком сложно. Чтобы создавать ПО, компании нужно было подняться до уровня Microsoft или Oracle. Но теперь, благодаря третьей великой эре программного обеспечения и цифровой цепочке поставок, создание ПО не просто возможно, а необходимо. Эту необходимость диктует конкурентная динамика.
Вы связываете строительные блоки в целостное ПО, которое вам необходимо и которое обеспечивает ваше конкурентное преимущество. Но части, из которых создается ваше ПО, являются готовыми и быстро интегрируются в ваши программы. Вы добавляете в набор готовых элементов множество собственных микросервисов, создаете сервисы, которые составляют ваши конкурентные преимущества. Возможно, это собственный алгоритм ценообразования или логистический алгоритм, уникальный для вашей системы дистрибуции. Но использование готовых строительных блоков везде, где это можно, позволяет направить всю энергию на свои уникальные области дифференциации.
К счастью, все больше и больше этих готовых строительных блоков становятся зрелыми. Облачные платформы заменяют устаревшую инфраструктуру почти везде, где это возможно. Эти коммерческие микросервисы являются исходными ингредиентами почти всех используемых вами приложений. За пользовательским интерфейсом приложения в действительности имеется своего рода лоскутное одеяло, состоящее из сотен или даже тысяч микросервисов, некоторые из которых созданы собственными разработчиками компании, а некоторые — коммерческими поставщиками.
Ныне существует еще немало мест, где у разработчиков нет другого выбора, кроме создания микросервисов с нуля, поскольку готовых альтернатив просто не существует. Но прелесть модели использования микросервисов заключается в том, что микросервис можно встроить в любое место приложения, не нарушая остальной части кода. По мере появления новых коммерческих микросервисов разработчики зачастую удаляют собственные части кода и заменяют их коммерческими альтернативами. А все потому, что подобные коммерческие микросервисы становятся лучше с каждым днем, в то время как собственные разработки нередко не развиваются. Возьмем, например, Twilio — в период работы над этой книгой в нашем отделе исследований и разработок трудилось более тысячи человек, ежедневно совершенствовавших коммуникационную платформу. Наши клиенты получают выгоду от того, что наше приложение непрерывно улучшается.
Теоретически в один прекрасный день софтверная компания сможет создать приложение, вообще не написав собственного кода, а просто скомпоновав микросервисы, созданные другими компаниями. Фактически это идея компании, которая оценивается на рынке в $1 млрд или больше, но управляется одним человеком — разработчиком, чье приложение выстроено на основе коммерческих микросервисов. Такого пока не произошло, но это лишь вопрос времени. Процесс, который мы называем «написание ПО», может стать в значительной степени процессом объединения фрагментов кода — точно так же, как Dell собирает из готовых компонентов персональный компьютер или шеф-повар делает особенное блюдо из готовых ингредиентов. В действительности написание программы может вскоре оказаться таким легким делом, которое под силу любому человеку без специальной подготовки в области компьютерных наук.
Пока же существует гибридная модель. Вы покупаете общие части кода там, где возможно, а остальное пишете самостоятельно. Новым может быть то, как именно вы интегрируете готовые части и насколько хороша ваша программа на основе микросервисов, с которой взаимодействуют клиенты. В состав Apple iPhone входят готовые компоненты, такие как чипы памяти и флеш-накопители, которые может купить любая компания. Apple не разрабатывает и не создает собственные версии этих компонентов, с тем чтобы сделать свой продукт лучше других смартфонов. Но Apple разрабатывает специальный микропроцессор для iPhone, потому что он улучшает работу iPhone. Apple также пишет все ПО для iPhone. Ноу-хау Apple — это знание того, какие компоненты iPhone покупать, а какие создавать самостоятельно; знание того, как интегрировать эти части уникальным образом, и, самое главное, привлечение лучших разработчиков планеты. Apple также всегда знала, как преподнести свою историю и продать свой бренд — это еще одна область, где она решила дифференцироваться, и это решение окупилось в полной мере.
Точно так же, как и Apple, разработчики теперь сочетают собственное ПО с готовыми микросервисами, предоставляемыми другими. Хороший пример — Uber. То, что вы называете «приложение Uber», на самом деле представляет собой набор примерно из 4000 микросервисов, некоторые из которых разработаны инженерами Uber, а многие предоставляются внешними операторами облачных платформ. Когда пассажир звонит водителю, его команда мгновенно перемещается с главного экрана Uber на наши серверы Twilio, и мы направляем вызов водителю. Но это все невидимо ни для пассажира, ни для водителя — они лишь знают, что Uber позволяет им связаться друг с другом. Платежи обрабатываются другим микросервисом, в то время как конвертация валют осуществляется микросервисом Tincup, который Uber разработала самостоятельно.
Именно так все новые компании в Кремниевой долине создают свое ПО, быстро превращающееся в стандарт для традиционных компаний, таких как банки, розничные продавцы и авиакомпании.
Некоторые компании считают, что такие услуги, как вычисления, хранение данных, платежи или связь, являются основными и не могут передаваться на аутсорсинг. Например, я знаю розничные компании, которые на заре существования облака отказались использовать платформу AWS, поскольку розничный бизнес Amazon был их конкурентом. Однако компании с таким отношением к делу уходят на второй план. Именно когда конкуренция становится более жесткой, компании должны сосредоточиться на том, что дифференцирует бизнес. Покупка готовых решений даже у самого опасного конкурента — как раз то, что позволяет получить шанс на победу. Вот почему вы смотрите фильмы и видеопрограммы на сервисе Netflix, который конкурирует с Amazon Prime Video, — а ведь Netflix является крупным и публичным клиентом платформы AWS. Вот почему в Twilio мы видим, как крупные операторы используют наши сервисы для контакт-центров, рассылки уведомлений клиентам и многого другого. Часто решения не использовать облачные сервисы принимаются на самом верху из-за… ошибочной стратегии компании. Я полагаю, что это неразумно.
Руководители должны обращаться к своим разработчикам и техническим специалистам за помощью в принятии таких решений. Это уже происходит естественным образом. Разработчики создают ПО на основе платформ AWS и Twilio и оплачивают их использование своими кредитными картами. Вместо того чтобы ругать разработчиков, лидеры компаний должны воспринимать эту естественную тягу к созиданию как сигнал и следовать за ними.
Мне вспоминается история Джо Маккоркла, вице-президента по телекоммуникациям в RealPage, крупной публичной софтверной компании, обслуживающей индустрию аренды многоквартирных домов. Она предлагает десятки SaaS-продуктов для компаний, которые владеют и управляют недвижимостью, такой как многоквартирные дома. А еще эта компания очень активна в сфере поглощений. В последнее десятилетие число ее поглощений исчисляется десятками. В 2012 г., после того как она приобрела несколько стартапов, которые были клиентами Twilio, их счета начали приходить к Джо на одобрение, поскольку он отвечал за расходы на связь. Сначала он не обращал на них внимания, но затем операционный директор попросил Джо «выяснить, что это за штука Twilio и можно ли избавиться от нее», например заменив Twilio услугами, которые они уже покупали у оператора связи или телекоммуникационной компании.
Джо пришел на нашу ежегодную конференцию клиентов в 2012 г., тогда называвшуюся TwilioCON, с целью выяснить, что Twilio вообще делает и как он нас уничтожит. Там он познакомился с сотнями других наших пользователей и получил представление о том, сколько компаний используют Twilio для создания инноваций в сфере обслуживания клиентов. Здравый смысл у Джо возобладал, и на обратном пути он написал меморандум, в резюме которого говорилось: «Мы не отказываемся от Twilio, мы перемещаем всю свою деятельность в облачные сервисы Twilio». И в последние годы RealPage поступает именно так.
Это отличный пример того, как Джо последовал за своими разработчиками, которые были в курсе новейших тенденций в своей сфере. Когда вы создаете свою команду разработчиков, фундаментальная задача ее членов состоит в определении правильных областей создания ПО. Принятие решений о том, какие области являются ключевыми компетенциями компании, — вопрос, часто обсуждаемый руководителями компаний, — теперь спустилось на уровень микросервисов. Я не жду, что большинство руководителей компаний приобретут опыт или желание инспектировать работу на этом уровне, но они должны понимать, что их технические команды принимают такие решения довольно часто. Руководители должны быть в курсе доступных услуг и настоятельно поощрять команды к использованию «строительных блоков», ускоряющих создание ценности для клиентов. Также необходимо постоянно спрашивать технические команды о том, на какие области следует переключить их таланты. Это не разовое решение в духе «создать или купить». Ответ при использовании микросервисов будет со временем меняться. И к этому вопросу стоит возвращаться регулярно.
Разработчики обычно первыми узнают о новом и интересном в цифровой цепочке поставок. Вы можете поинтересоваться у них, насколько легко им принимать современные API, или подумать, какие ограничения компания накладывает на их принятие. Как вообще сбалансировать потребность в безопасности с желанием позволить разработчикам использовать самые современные сервисы? Спросите свою команду, не покупают ли они тайно эти услуги цифровой цепочки поставок. Если да, то не наказывайте их. Поймите, почему так происходит, и выясните, как формализовать возможности разработчиков совершать такие покупки. Спросите своих разработчиков, как они определяют, что можно купить, а что действительно позволяет дифференцировать вашу компанию.
Войти с помощью соц. сетей: