Непрерывное развитие API. Правильные решения в изменчивом технологическом ландшафте, 2-е изд. E-Book

Мехди Меджуи

• Herausgeber: Питер
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Russisch

Seitenzahl: 528

Veröffentlichungsjahr: 2023

Beschreibung

Для реализации API необходимо провести большую работу, но эти усилия не всегда окупаются. Чрезмерное планирование может стать пустой тратой сил, а его недостаток приводит к катастрофическим последствиям. Во втором издании представлены решения для отдельных API и систем из нескольких API, которые позволят вам распределить необходимые ресурсы и достичь требуемого уровня эффективности за оптимальное время. Как соблюсти баланс гибкости и производительности, сохранив надежность и простоту настройки? Четыре эксперта по API объясняют разработчикам, руководителям продуктов и проектов, как максимально увеличить ценность их API, управляя интерфейсами как продуктами с непрерывным жизненным циклом.

Leseprobe

Мехди Меджуи, Эрик Уайлд, Ронни Митра, Майк Амундсен

Непрерывное развитие API. Правильные решения в изменчивом технологическом ландшафте, 2-е изд.

2023

Переводчик С. Черников

Мехди Меджуи, Эрик Уайлд, Ронни Митра, Майк Амундсен

Непрерывное развитие API. Правильные решения в изменчивом технологическом ландшафте, 2-е изд.. — СПб.: Питер, 2023.

ISBN 978-5-4461-2023-9

© ООО Издательство "Питер", 2023

Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

Отзывы о книге

Впечатляет, что авторам удалось сделать эту книгу об API в целом, а не о конкретных технологиях. Независимо от выбранной вами технологии API, вы определенно получите ценные рекомендации.

Стефан Тильков, генеральный директор и главный консультант INNOQ

API — это основа современного предприятия. Эта книга станет вашим руководством по внедрению вездесущих API и управлению ими.

Грегор Хохпе, автор книги The Software Architect Elevator

«Непрерывное развитие API» — отличное руководство для тех, кто отвечает за создание и масштабирование своей программы API. От практических советов до глубокого погружения во все аспекты реализации программы API — эта книга станет незаменимым ресурсом для всех, от руководителей до специалистов-практиков API.

Джеймс Хиггинботэм, консультант по API и автор книги Principles of Web API Design

Многочисленные печатные издания подробно описывают тонкости создания веб-API. Однако книга «Непрерывное развитие API» стоит особняком как целостное руководство. Она обязательна к прочтению для руководителей проектов.

Мэтью Рейнболд, автор информационного бюллетеня Net API Notes и директор по экосистемам API и цифровой трансформации в Postman

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

Хибри Марзук, главный консультант компании Contino

«Непрерывное развитие API» — всеобъемлющая книга, посвященная управлению продуктами API. Она полна практических рекомендаций, и я знаю, что множество организаций использовали информацию из нее для продвижения своих цифровых стратегий с использованием API.

Мэтт Макларти, руководитель по стратегии API в MuleSoft, компания Salesforce

Предисловие к первому изданию

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

Диджитал-трансформация, происходящая последние пять лет, привела к изменениям в среде API. Компании перестали задавать вопрос: «Надо ли нам использовать API?» и начали искать информацию, как правильно это делать. В организациях понимают, что недостаточно просто создать API. Многое зависит от разработки всего его жизненного цикла. Авторы книги «Непрерывное развитие API» хорошо понимают, что нужно для последовательного, масштабного и воспроизводимого перехода API от идеи к реализации. Это позволяет им стать уникальными наставниками в данной сфере.

Большинство специалистов работают с ландшафтом API, охватывающим только один набор API. Авторы этой книги обладают уникальным опытом работы с системой ландшафта API, охватывающей тысячи API, несколько отраслей и крупнейших современных предприятий. Высококлассных талантливых специалистов в этой области по всему миру можно пересчитать по пальцам. И Меджуи, Уайлд, Митра и Амундсен всегда будут первыми, кого я назову. Благодаря своему богатому опыту авторы помогают понять, как провести API от идеи до проекта, от разработки до производства. Нет другой команды экспертов по API, обладающей такими же уникальными знаниями. Эта книга может стать вашей настольной — тем зачитанным до дыр томиком, к которому вы будете возвращаться снова и снова.

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

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

Прочитав эту книгу, я почувствовал, что по-новому взглянул на современный жизненный цикл API. У меня появилось много идей о том, как я могу оценить и измерить свои операции API и стратегию их жизненного цикла, которую сейчас использую для управления этими операциями. Несмотря на мою высокую компетенцию в данной области, книга заставила меня посмотреть на эту среду по-новому. Я почувствовал, что наполнился информацией, которая не только освежила мои знания, но и изменила представления о том, что мне казалось известным. Она заставила меня расти над собой и развиваться в своей сфере деятельности.

На пути разработки API для меня главное — постоянно бросать себе вызов, учиться, планировать, выполнять, оценивать и повторять, пока не добьешься желаемого результата. «Непрерывное развитие API» отражает реальность разработки API. Это руководство по технологии, бизнесу и политике создания API в масштабе целого предприятия.

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

Кин Лейн, евангелист API

Вступление

Добро пожаловать на страницы второго издания «Непрерывного развития API»! Во вступлении издания 2018 года говорилось:

Когда общество и бизнес естественным образом тесно переплелись с цифровыми технологиями, спрос на взаимосвязанное программное обеспечение резко вырос. В свою очередь, интерфейс для программирования приложений (API) стал важным ресурсом для современных компаний, потому что он упрощает установление связей между ПО. Но управление этими API стало вызывать новые сложности. Чтобы получить от API максимум, необходимо научиться управлять их разработкой, запуском, ростом, качеством и безопасностью, учитывая сложные факторы контекста, времени и масштаба.

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

Мы добавили новые примеры и обновили существующие, но по-прежнему сохранили тот же базовый подход и основные положения. Надеемся, эти изменения помогут вам расширить свои познания на пути к непрерывному управлению API.

Для кого эта книга

Если вы только начинаете разрабатывать программу внедрения и использования API и вам нужно понять, что вас ждет, или у вас уже есть API, но вы хотите научиться лучше управлять ими, — эта книга для вас.

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

Мы постарались сделать книгу максимально технологически нейтральной. Советы и анализ, которыми мы делимся, подходят для любой архитектуры на основе API, включая HTTP (HyperText Transfer Protocol — протокол передачи гипертекста), CRUD (акроним, обозначающий четыре основные функции, используемые при работе с базами данных: создание (create), чтение (read), модификация (update), удаление (delete)), REST (Representational State Transfer — передача репрезентативного состояния), GraphQL и событийно-ориентированные стили взаимодействия. Это книга для тех, кто хочет принимать более эффективные решения при работе с API.

Что вас ждет в книге

Здесь изложен весь наш многолетний опыт проектирования, разработки и улучшения API — как своих, так и чужих. Мы определили два ключевых фактора эффективной разработки API (продуктоориентированный подход и создание правильной команды) и три фактора управления этой работой: руководство, развитие продукта и разработка ландшафта API.

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

Структура издания

Книга построена так, чтобы список важных вопросов рос по мере чтения. Мы начнем с основных понятий управления на основе решений и концепции «API как продукт», а затем сделаем обзор всей работы для создания API-продукта.

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

Ознакомимся с кратким содержанием всех глав.

• Глава 1 «Сложности и перспективы управления API» знакомит вас со сферой управления API.

• В главе 2 «Руководство API» управление рассматривается с точки зрения принятия решений — базовой концепции управления API.

• В главе 3 «API как продукт» мы рассказываем о важности концепции «API как продукт» для любой стратегии API.

• Глава 4 «Основы API-продукта» освещает десять базовых принципов работы в сфере API-продуктов, которые формируют систему задач по принятию решений, которыми нужно управлять.

• Глава 5 «Непрерывное улучшение API» дает представление о том, что означает постоянное изменение API. Мы рассказываем о необходимости принять идею постоянных изменений и знакомим с разными типами изменений в API и их последствиями.

• Глава 6 «Стили API» — новая глава в этом издании. В ней рассматриваются пять самых распространенных стилей API, встречающихся в компаниях по всему миру, и анализируются их сильные и слабые стороны, чтобы вы смогли выбрать подходящий для каждого конкретного случая.

• Глава 7 «Жизненный цикл API-продуктов» рассматривает жизненный цикл продукта API — структуру, которая поможет вам управлять работой API по десяти основным направлениям в течение всего времени работы API-продукта.

• Глава 8 «Команды API» рассказывает о человеческом факторе управления API — типичных ролях, зонах ответственности и схемах разработки для команды, разрабатывающей API.

• Глава 9 «Ландшафты API» добавляет перспективу масштабирования к проблеме управления API. В ней приведены «восемь V» — разнообразие (variety), словари (vocabulary), объем (volume), скорость (velocity), уязвимость (vul­nerability), видимость (visibility), контроль версий (versioning) и изменяемость (volatility), — которые нужно учитывать при одновременном изменении нескольких API.

• В главе 10 «Путешествие по ландшафту API» мы освещаем подход непрерывной разработки системы для постоянного и согласованного управления изменениями API.

• Глава 11 «Управление жизненным циклом API в меняющемся ландшафте» сопоставляет перспективу ландшафта с перспективой API как продукта и определяет, как меняется работа API, когда вокруг него развивается ландшафт.

• Глава 12 «Продолжение путешествия» суммирует изложенную информацию по управлению API и дает советы о том, как подготовиться к будущей работе и сразу же начать ее.

Чего вы здесь не найдете

Сфера управления API обширна и содержит огромное множество вариантов контекстов, платформ и протоколов. К сожалению, в эту книгу просто не поместятся все конкретные способы реализации API. Это не руководство по разработке REST API или выбору шлюза безопасности. Здесь вы не найдете пошаговую инструкцию по написанию кода для API или разработке HTTP API.

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

Условные обозначения

В книге применяются следующие обозначения.

Курсив

Обозначает новые термины и слова.

Рубленый шрифт

Им набраны URL, адреса электронной почты.

Моноширинныйшрифт

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

Обозначает совет или предложение.

Обозначает примечание.

Обозначает предупреждение.

Благодарности

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

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

Дополнительная благодарность сотрудникам NGINX, которые вдохновили нас на доработку этой книги и помогли с финансированием. Отдельное спасибо всем, кто читал ранние черновики и помог нам сформировать окончательный вариант книги.

Мы также хотели бы поблагодарить Джеймса Хиггинботэма, Хибри Марзука, Марьюкку Нииниойя и Мэтью Рейнболда за все то время, которое они потратили на чтение и рецензирование нашей работы.

И конечно, все это было бы невозможно без поддержки сотрудников O’Reilly Media. Мы благодарим Мелиссу Даффилд, Гэри О’Брайена, Кейт Гэллоуэй, Ким Уимпсетт и многих других, кто посвятил свое время и талант тому, чтобы помочь нам собрать все воедино.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Глава 1. Сложности и перспективы управления API

Управление — это прежде всего занятие на стыке искусства, науки и ремесла.

Генри Минцберг

Согласно отчету IDC за 2019 год, 75 % опрошенных компаний ожидают «цифровой трансформации» в следующем десятилетии и что 90 % всех новых приложений будут иметь микросервисную архитектуру на базе API1. Было также отмечено, что для организаций, ориентированных на API, до 30 % дохода генерируется через цифровые каналы. В то же время эти компании определили ключевые препятствия для внедрения API — «сложность», «безопасность» и «управление».

Вот один из важных итоговых выводов: «Определение правильной архитектуры приложений требует глубокого понимания проблем, связанных с регулированием, управлением и координацией этих основных технологических компонентов»2.

Это исследование, как и исследование Коулмана Паркса (https://oreil.ly/pAWGs), которое мы приводили в первом издании, одновременно и ободряет, и предостерегает.

Интересная тенденция, которую мы наблюдаем последние несколько лет, — увеличивающийся разрыв между «имеющими API» и «не имеющими API». Например, на вопрос «Есть ли у вашей компании платформа для управления API?» 72 % компаний в сфере медиа и услуг ответили «да», тогда как в производственном секторе утвердительно ответили только 46 % компаний3. Все указывает на то, что API будут и дальше стимулировать рост бизнеса, и крайне важно, чтобы компании из всех ниш приняли вызов цифровой трансформации.

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

Мы имели опыт общения с компаниями, которые неохотно делятся своими знаниями в этой области. Они уверены, что навыки в этой сфере — конкурентное преимущество, и редко открывают свои тайны.

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

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

Главная сложность — понять, что именно люди подразумевают под API. Во-первых, термин API может относиться просто к интерфейсу (например, URL HTTP-запроса и возвращаемый JSON). Во-вторых, он может применяться к коду и элементам развертывания, необходимым для создания доступного сервиса (например, customerOnBoarding API). И в-третьих, иногда этот термин относится к конкретному экземпляру приложения, предоставляющего доступ через API (например, customerOnBoarding API, запущенный в облаке AWS, в отличие от customerOnBoarding API, запущенного в облаке Azure).

Другая важная проблема в управлении API — это разница между работой по проектированию, созданию и выпуску одного API и поддержкой и управлением множества API — так называемым ландшафтом API. В книге мы подробно рассмотрим все эти проблемы. В работе с одним API могут помочь такие понятия, как «API как продукт» (API as a product, AaaP), и важные навыки для создания и поддержки API (они же базовые принципы API). Мы поговорим и о таких важных аспектах, как роль модели зрелости API и работа с постепенными его изменениями.

Другая сторона проблемы — управление ландшафтом API. В данном случае ландшафт — это API всех бизнес-доменов, запущенные на всех платформах и управляемые всеми командами, разрабатывающими API в вашей компании. Есть несколько аспектов этой ландшафтной проблемы, в том числе то, как масштаб и контекст изменяют способ разработки и реализации API, и то, как большие экосистемы могут создавать дополнительную нестабильность и уязви­мость только из-за своего размера.

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

Прежде чем начать изучение способов работы с индивидуальными API и ландшафтом API, рассмотрим два важных вопроса: что такое управление API и в чем его сложность?

Что такое развитие API

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

API в бизнесе

Помимо деталей создания API и управления ими важно помнить, что вся эта работа предназначена для поддержания бизнес-целей и задач. API — это не только технические детали JSON или XML, синхронности или асинхронности и т.д. Это способ соединять подразделения бизнеса, делиться важными знаниями и функциями, увеличивая эффективность работы компании. Часто API — это возможность раскрыть то ценное, что уже есть в организации, например, при создании новых приложений, открытии новых источников дохода и создании нового бизнеса.

Такой способ мышления фокусируется на нуждах потребителей API, а не тех, кто их создает и публикует. Этот клиентоориентированный подход обычно называют «работа, которая должна быть выполнена», или JTBD (Jobs to Be Done). Его предложил Клейтон Кристенсен из Гарвардской школы бизнеса, и в своих книгах The Innovator’s Dilemma4 и The Innovator’s Solution5 (Harvard Business Review Press) он тщательно исследует возможности такого подхода. Его основ­ная идея в том, что для запуска успешной API-программы и управления ею нужно помнить: API важны в первую очередь для решения задач бизнеса. По нашему опыту, компании, которые умеют применять API для бизнеса, относятся к своим API как к продуктам для «выполнения работы» в том же смысле, в каком JTBD Кристенсена решает проблемы потребителей.

• Доступ к данным. Один из способов, которым API может помочь бизнесу, — это упрощение доступа к важным данным о клиентах или рынке, которые можно сопоставить с возникающими тенденциями или уникальным поведением в новых нишах рынка. API обеспечивает безопасный и легкий доступ к этим данным (анонимизированным и отфильтрованным), помогая вашему бизнесу открывать новые возможности, реализовывать новые продукты или услуги или даже создавать новые инициативы быстрее и дешевле.

• Доступ к продуктам. Еще один способ, которым программа API может помочь бизнесу, — создание гибкого набора «инструментов» (API) для новых решений без больших затрат. Например, если у вас есть API онлайн-продаж OnlineSales, позволяющий важным партнерам отслеживать активность своих продаж и управлять ею, и API маркетинга и акций MarketingPromotions, позволяющий специалистам разрабатывать и отслеживать рекламные кампании продукта, то у вас есть возможность создать новое партнерское решение: приложение для отслеживания продаж и рекламы SalesAndPromotions.

• Доступ к нововведениям. Во многих компаниях есть внутренние процессы, практики и производственные конвейеры, которые эффективны, но нецелесообразны. Некоторые из них существуют уже давно (иногда — десятилетия). Нам встречались случаи, когда никто не мог вспомнить дату или причину внедрения в организацию того или иного процесса.

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

Эти важные аспекты (AaaP) мы рассматриваем в главе 3. Но сначала давайте кратко пройдемся по термину API.

Что такое API

Иногда, используя термин API, люди подразумевают не только интерфейс, но и функциональность — код, скрывающийся за интерфейсом. Например, можно сказать: «Нам нужно поскорее выпустить обновленный клиентский API, чтобы другие команды смогли задействовать новые функции поиска, которые мы добавили». В других случаях этот термин может применяться только в отношении деталей самого интерфейса. Например, сотрудник вашей команды может сказать: «Я бы хотел разработать новый JSON API для существующих SOAP-сервисов добавления клиентов в систему (customer onboarding)». Оба случая употребления термина верны, и в обоих понятно, что имелось в виду, но иногда можно и запутаться.

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

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

• открыть новую учетную запись;

• редактировать профиль уже существующей учетной записи;

• изменить (заморозить или активировать) статус учетной записи.

Такой интерфейс обычно предоставляется через такие общеупотребимые протоколы, как HTTP, MQTT, Thrift, TCP/IP и т.д., и опирается на такие стандартизированные форматы, как JSON, XML, YAML или HTML.

Но это только интерфейс. Нужно еще что-то для выполнения задач. Это что-то мы в дальнейшем будем называть реализацией. Реализация — та часть системы, которая обеспечивает фактическую функциональность. Обычно она написана на языке программирования (Java, C#, Ruby, Python и т.п.).

В рамках примера с пользовательской учетной записью реализация UserMana­gement (Управление пользователями) может содержать возможность создавать, добавлять, редактировать и удалять пользователей. Затем эта функциональность передается с помощью вышеупомянутого интерфейса.

Отделение интерфейса от реализации

Обратите внимание, что функциональность описанной реализации — это простой набор действий с использованием шаблона «создать, прочесть, обновить, удалить» (CRUD), а в упомянутом интерфейсе есть три действия: OnboardAccount (Активировать учетную запись), EditAccount (Редактировать учетную запись) и ChangeAccountStatus (Изменить статус учетной записи). Это кажущееся несовпадение между реализацией и интерфейсом широко распространено и может оказаться полезным. Оно разъединяет конкретную реализацию каждого сервиса и интерфейс, используемый для доступа к нему, упрощая изменения без прерывания работы.

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

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

Рис. 1.1. Три элемента API

Стили API

Еще один важный элемент API — то, что можно назвать стилем. Как и стили в других областях (живопись, декор, мода и архитектура), стили API — это последовательные идентифицируемые подходы к созданию и использованию API. Важно знать, какой стиль API хотят использовать ваши клиентские приложения, и обеспечить его последовательное применение при создании своих реализаций API.

Самый распространенный стиль API на сегодняшний день — REST, или RESTful API. Но это только один из множества вариантов. На самом деле сегодня все чаще можно наблюдать, как организации разных размеров используют интерфейсы, отличные от REST и не связанные с HTTP. Развитие событийно-ориентированной архитектуры (EDA) — один из примеров этой новой реальности для управления API.

Несмотря на существование множества уникальных стилей, есть пять общепринятых, о которых важно знать при управлении программой API. Мы расскажем о важности стилей API и рассмотрим каждый из них в главе 6.

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

Такая многостилевая реальность API приводит к другому важному аспекту успешных API-программ: способности согласованно и последовательно управлять множеством API.

Больше чем просто API

В книге мы не ограничиваемся только рассмотрением API — техническими деталями его интерфейса и реализации. Конечно, традиционные элементы «проект — разработка — реализация» важны для ваших API. Но управление API также подразумевает и тестирование, документирование и публикацию их на портале, чтобы пользователи (разработчики организации, партнеры, сторонние анонимные разработчики приложений и т.д.) могли их найти и правильно применить.

API важно защищать, следить за их работой и поддерживать ее (включая все изменения) в течение всего срока их службы. Такие дополнительные действия мы называем базовыми принципами API. Это элементы, необходимые для всех API, с которыми приходится сталкиваться специалистам в этой области. Базовые принципы мы подробнее рассмотрим в главе 4, где изучим список из десяти основных методик, необходимых для создания и поддержки качественных API.

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

Создание и организация команд, разрабатывающих API, — еще один важный аспект управления ими. Подробнее об этом мы поговорим в главе 8.

Стадии API

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

Может показаться правильным при планировании, разработке и релизе API учитывать все их базовые принципы. Но это не так. Часто на ранних этапах лучше всего уделить внимание планированию и разработке, затрачивая меньше сил, допустим, на документацию.

На других этапах (например, когда прототип оказывается в руках бета-тестеров) важнее уделять больше времени мониторингу использования API и его защите от неправомерного применения. Чем лучше вы будете ориентироваться в этих этапах, тем проще вам будет распределить свои ресурсы для достижения максимального результата. Мы подробнее поговорим об этом в главе 7.

Больше одного API

Многие знают, что управление большим количеством API влечет за собой серьезные изменения. У нас есть клиенты, которым нужно разработать и отслеживать тысячи API и управлять ими в течение долгого времени. В такой ситуации люди меньше сосредоточены на деталях реализации отдельного API и больше — на том, как все эти API сосуществуют в постоянно растущей динамичной экосистеме. Как уже упоминалось, мы называем эту экосистему ландшафтом API. Ей будут посвящены несколько глав во второй половине книги.

В такой ситуации сложно обеспечить некоторый уровень согласованности, не вызывая задержек из-за централизованного управления и проверки всех деталей API. Обычно такого уровня достигают, передавая ответственность за эти вопросы отдельным командам API и сосредоточивая усилия центрального управления на упорядочении взаимодействия API между собой. Это обес­печивает наличие базового набора общих сервисов или инфраструктуры (безопасность, контроль и т.д.) и их доступность для всех команд API. Более автономным командам предоставляются общее руководство и поддержка. Другими словами, часто приходится отходить от привычной централизованно-административной модели.

Одна из сложностей при передаче командам прав на самостоятельное принятие решений в том, что вышестоящее руководство может легко упустить из виду важные действия, происходящие на уровне этих команд. Раньше сотрудникам приходилось просить разрешение на выполнение определенных действий, но теперь компании, предоставляющие дополнительную автономию отдельным командам, будут побуждать их действовать, не дожидаясь проверки и разрешения «сверху».

Сложность управления средой API связана в основном с масштабом и объемом. Оказывается, по мере роста ваша API-программа еще и меняет форму. Это мы и обсудим далее.

Сложности в управлении API

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

Мы выделили несколько основных тем, которые затрагиваем на встречах с компаниями по всему миру, когда обсуждаем управление жизненным циклом API.

• Объем. На чем должны сосредоточиться команды по архитектуре центрального программного обеспечения при долгосрочном управлении API?

• Масштаб. Зачастую то, что работает, когда компании только начинают заниматься API, перестает работать, когда программа из нескольких небольших команд разрастается до глобальной инициативы.

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

Именно постоянный баланс объема, масштаба и стандартов создает жизнеспособную и растущую программу по управлению API. Поэтому стоит рассмотреть каждую составляющую подробнее.

Объем

Одна из самых больших сложностей в работе с исправной программой управления API — достичь оптимального уровня централизованного контроля и, что еще сложнее, — чтобы оптимальный уровень менялся вместе с развитием программы.

На ранних этапах лучше всего сосредоточиться на элементах проектирования API. В случаях, когда API еще в зачаточном состоянии, эти элементы могут исходить напрямую от команды создателей. Они изучают существующие программы «в полевых условиях», выбирают инструменты и библиотеки, подходящие для стиля того API, который они планируют создать, и затем разрабатывают его.

Именно на этом начальном этапе жизни API в организации подробные рекомендации и четкое распределение ролей помогут вам скорее добиться успеха. В главах 3 и 4 вы найдете множество материалов, полезных для компаний — новичков в этой области.

На первоначальном этапе развития API все в новинку. Все проблемы возникают (и решаются) впервые. Этот опыт часто в конечном итоге записывается в «лучшие практики API» или документацию компании и т.д. Он важен для маленькой команды, работающей над несколькими API в первый раз. Но эти руководства могут оказаться неполными.

С увеличением количества API-команд в компании растет и разнообразие стилей, ситуаций и точек зрения. Становится сложнее поддерживать стабильность во всех командах, и не только потому, что некоторые не соблюдают инструкции компании. Возможно, следовать этим инструкциям мешает работа с другим набором готовых продуктов. Возможно, причина в том, что члены команды не работают в среде с потоком событий, а поддерживают API, основанные на XML, в режиме «запрос — ответ». Конечно, им тоже нужно руководство, но оно должно соответствовать их сфере и потребностям их клиентов.

На «промежуточном этапе» вашей программы управления API инструкции должны перейти от конкретных предписаний по разработке и внедрению API к более общим рекомендациям по их жизненному циклу и способам взаимодействия. В главах 6 и 7 вы узнаете, что делают успешные организации для программ API на среднем этапе.

Конечно, есть универсальные инструкции для всех команд, но они должны соответствовать сферам их задач и запросам пользователей их API. С расширением вашего сообщества увеличивается и вариативность. И попытка ее уничтожить ознаменует ваш провал. Здесь вам следует сместить фокус контроля с директивных распоряжений (например, «все API должны использовать следующие схемы URL…») на указание направлений (например, «API, работающие на HTTP, могут использовать один из следующих шаблонов URL…»).

На «позднем этапе» перспектива управления расширяется сильнее и фокусируется на том, как ваши API взаимодействуют между собой и с API других компаний в вашем отраслевом секторе. Главы 9, 10 и 11 отражают тип мышления «видения целостной картины», важный для поддержания здоровой и стабильной экосистемы API в будущем.

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

Это подводит нас к следующему ключевому элементу — масштабу.

Масштаб

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

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

Ландшафт API ставит перед вами новые задачи. Процессы, используемые для разработки, реализации и поддержки одного API, не всегда совпадают с теми, которые нужны при расширении экосистемы. Здесь работает закон больших чисел: чем больше API в вашей системе, тем вероятнее их взаимодействие друг с другом. Это создает риск того, что некоторые из таких взаимодействий приведут к неожиданным последствиям (или ошибкам). Так работают все крупные системы: больше взаимодействий — больше неожиданных результатов. Попытки избавиться от них решат только часть проблемы. Удалить все баги невозможно.

И это приводит к третьей проблеме, с которой сталкивается большинство растущих программ API: как уменьшить количество неожиданных изменений, применяя в программе соответствующий уровень стандартов?

Стандарты

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

Чем больше в компании рабочих групп, тем выше будут расходы на координацию их совместных действий (см. раздел «Решения» на с. 41). Увеличение масштаба требует изменений в объеме работ. Разобраться с этим будет проще, полагаясь на общие стандарты, а не на конкретные ограничения.

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

Все долгосрочные стандарты, которые помогали интернету успешно функцио­нировать, объединяет фокус на стандартизации взаимодействия между компонентами и системами. Вместо того чтобы стандартизировать способы внутренней реализации компонентов (например, используйте эту библиотеку, эту модель данных и т.д.), веб-стандарты стремятся облегчить взаимопонимание сторон. Когда ваша API-программа поднимается на более высокий уровень, указания вашему сообществу API тоже должны быть сосредоточены на общих стандартах взаимодействия, а не на конкретных деталях реализации.

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

Управление ландшафтом API

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

У ландшафтов API есть свои сложности, свое поведение и тенденции. То, что вам нужно учитывать при разработке одного API, отличается от того, что вы должны учитывать, когда вам нужно поддерживать десятки, сотни или даже тысячи. В экосистеме появляются проблемы с масштабом, которых не возникало в ходе работы с одной программой или реализацией API. Мы подробнее остановимся на ландшафте позже, а сейчас хотим упомянуть три области, в которых появляются уникальные для управления API:

• масштабирование технологий;

• масштабирование команд;

• масштабирование руководства.

Рассмотрим каждый из этих аспектов в отношении к ландшафтам.

Технология

Во время первого запуска программы API нужно принять серию технических решений, которые повлияют на все ваши API. Тот факт, что «все» ваши API — это лишь небольшой набор, сейчас не важен. Важно то, что у вас есть стабильный набор инструментов и технологий, на которые вы полагаетесь при разработке изначальной API-программы.

Когда вы доберетесь до рассмотрения деталей жизненного цикла API (см. главу 7) и развития API, то увидите, что стоимость таких программ весьма высока и вам нужно тщательно контролировать свои затраты времени и энергии на деятельность, которая серьезно повлияет на успех вашего API. Обычно это значит, что нужно выбрать и поддерживать небольшой набор инструментов и предоставить четкие и детализированные документы с указаниями, чтобы помочь вашим специалистам создать и разработать те API, которые решат проблемы бизнеса и будут хорошо сочетаться друг с другом. Иначе говоря, на ранних этапах можно сэкономить, ограничивая технический объем.

На первых порах это хорошо работает по всем вышеупомянутым причинам. Но как только объем (см. раздел «Объем» на с. 277) программы увеличивается (например, больше команд начинают разрабатывать больше API, чтобы обслужить больше сфер бизнеса и т.д.), появляются сложности. Привязка к ограниченному набору инструментов и технологий может сильно замедлить работу. Вначале, при небольшом количестве команд, ограничение выбора ускоряло процесс. Но когда команд много, ограничения — затратное и рисковое предприятие, особенно если они находятся далеко друг от друга или же если вы создаете новые бизнес-подразделения или приобретаете новые компании, чтобы добавить их в свой ландшафт API. Здесь разнообразие (см. раздел «Разнообразие» на с. 271) становится более важным фактором для успешного развития вашей экосистемы.

Итак, в управлении технологиями ландшафта API важно понять, когда он стал достаточно большим, чтобы начать увеличивать разнообразие технологий, а не ограничивать их. Если ландшафт API должен поддерживать существующие в организации сервисы SOAP-over-TCP/IP, нельзя требовать, чтобы все эти сервисы использовали одно и то же руководство по URL, которое вы составили для новых API на CRUD-over-HTTP. То же самое касается создания сервисов для новых событийно-ориентированных реализаций Angular или устаревших реализаций удаленного вызова процедур (RPC).

Более широкий охват означает большее технологическое разнообразие в вашем ландшафте.

Команды

Технологии — не единственный аспект управления API, который сталкивается с новыми задачами при росте программы. Состав самих команд тоже должен корректироваться по мере изменения ландшафта. Опять же в начале работы над программой с API можно работать всего с несколькими универсальными специалистами. К ним относятся full-stack-разработчик, или MEAN-разработчик (MongoDB, Express.js, Angular.js, Node.js), или какой-либо другой вариант идеи одного разработчика с навыками для всех аспектов вашей программы API. Вы также, скорее всего, слышали о стартап-командах или автономных командах. Все это сводится к наличию необходимых вам навыков у членов одной команды.

Прибегать к услугам таких специалистов имеет смысл, когда у вас мало API и все они разрабатываются и реализуются с помощью одного набора инструментов (см. раздел «Технология» на с. 35). Но при увеличении масштаба и объема программы растет и число необходимых навыков для ее разработки и поддержки. Уже нельзя ожидать, что в каждой команде по API будет нужное количество людей, имеющих навыки в областях разработки баз данных, серверных и клиентских приложений, тестирования и развертывания программы. У вас может трудиться группа специалистов, чьей задачей будет разработать интерфейс панели управления, ориентированный на обработку данных, который станут применять другие команды. Их навыки должны включать в себя, например, использование всех форматов данных и необходимых инструментов для их сбора. Или у вас может быть команда для разработки мобильных приложений, применяющих одну технологию, например GraphQL или другую библиотеку, ориентированную на запросы. По мере роста технологического разнообразия вашим командам может потребоваться специализация. Эту тему мы подробнее рассмотрим в главе 8.

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

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

От этой проблемы можно избавиться, разбив процесс принятия решений на так называемые элементы решения (см. раздел «Элементы решения» на с. 52) и распределив их на соответствующих уровнях внутри компании. Рост экосистемы означает, что команды должны стать более специализированными на техническом уровне и более ответственными на уровне принятия решений.

Руководство

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

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

Например, мы обнаружили, что руководство API-программой на ранней стадии часто принимает форму длинного документа по процессу, объясняющего конкретные задачи: как создать URL для API, какие названия подходят для URL или где в HTTP должен быть номер версии. Четкие указания по выполнению небольшого количества опций позволяют разработчикам не отклоняться от утвержденного способа реализации API.

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

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

Другой прекрасный пример принципиальных указаний можно найти в большинстве руководств по UI/UX, например «10 удобных в применении эвристик для разработки пользовательского интерфейса» от Якоба Нильсена (https://oreil.ly/qU66X). В таких документах есть множество вариантов и обоснований для использования одного шаблона пользовательского интерфейса вместо другого. Они разъясняют, почему и когда что-либо применять, а не просто диктуют требования, которым нужно подчиняться.

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

Так, при росте ландшафта API модель руководства должна измениться с директивных указаний через общие принципы на сбор и передачу методик, используемых опытными командами, внутри компании. В главе 2 вы увидите, что можно задействовать много разных принципов и методик для создания модели руководства, подходящей именно вам.

Итоги главы

В этой вводной главе мы коснулись ряда важных аспектов управления API, описанных в книге. Рассказали, что API продолжают оставаться движущей силой, но лишь около 50 % опрошенных компаний уверены, что правильно ими управляют. Мы также пояснили, что у термина API много значений и это может усложнить создание стабильной модели управления программой.

А важнее всего то, что управление одним API очень отличается от управления ландшафтом API. В первом случае вы можете полагаться на модели AaaP, «жизненный цикл API» и «развитие API». Управление изменениями в API также сосредоточено на понятии одного API. Но это далеко не всё.

Затем мы обсудили управление ландшафтом API — целой экосистемой внутри организации. Управление растущим ландшафтом API требует другого набора навыков и параметров — навыков работы с разнообразием, объемом, изменяемостью, уязвимостью и другими характеристиками. Все они влияют на жизненный цикл API, и мы подробнее рассмотрим их позже.

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

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

1Thomson J., Mironescu G. APIs: The Determining Agents Between Success or Failure of Digital Business («API: факторы, определяющие успех или провал цифрового бизнеса») // IDC, https://oreil.ly/9yshw.

2Там же.

3Там же.

4Кристенсен К. Дилемма инноватора. Как из-за новых технологий погибают сильные компании.

5Кристенсен К., Рейнор М. Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост.

6На стриминговом музыкальном сервисе Spotify эти пересекающиеся группы называются гильдиями. Больше информации вы найдете в разделе «Масштабирование команд» на с. 243.

Глава 2. Руководство API

Эй, правила есть правила, и давайте признаем: без них наступает хаос.

Космо Крамер

Мало кто хочет, чтобы им руководили, — у большинства был отрицательный опыт работы под руководством тех, кто плохо планировал свои действия и устанавливал бессмысленные правила. Плохое руководство, как и плохое планирование, усложняет жизнь. Но по нашему опыту, трудно говорить об управлении API, не затрагивая его.

Мы даже позволим себе сказать, что управлять API без руководства невозможно.

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

Вопрос о необходимости в руководстве API не вызывает у нас интереса, ведь, по нашему мнению, ответ на него всегда утвердительный. Вместо этого спросите себя: «Какими решениями нужно руководить и где?» В поиске ответов на такие вопросы и заключается работа по созданию системы руководства.

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

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

Руководство — центральная часть управления API. Понятия из этой главы будут всплывать на протяжении всей книги. Поэтому стоит потратить время, чтобы понять, что на самом деле означает «руководство API» и как оно может помочь вам создать эффективную систему управления API.

Что такое руководство API

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

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

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

Решения

Чем качественнее будут ваши решения, тем лучших результатов вы добьетесь. Интерфейсы API — это в первую очередь технологический продукт, но для создания лучших API вам нужно принимать решения, которые выходят далеко за рамки написания хорошего кода.

Рассмотрим список решений, которые часто принимают команды разработчиков API.

• Какой URL будет у нашего API — /payments или /PaymentCollection?

• В каком облачном сервисе разместить наш API?

• У нас есть два API по клиентской информации, от которого из них отказаться?

• Кто войдет в команду по разработке?

• Как назвать эту переменную в Java?

На основании этого краткого списка решений можно сделать несколько выводов. Во-первых, варианты управления API охватывают широкий спектр проблем и людей, поэтому для принятия таких решений нужна тесная координация между командами. Во-вторых, индивидуальные решения сотрудников могут оказать разное влияние — выбор облачного сервиса повлияет на вашу стратегию управления API сильнее, чем название переменной в Java. В-третьих, небольшой выбор может сильно повлиять на масштабирование — если 10 000 переменных в Java будут названы плохо, поддерживать реализации API будет гораздо сложнее.

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

Управление принятием решений

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

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

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

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

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

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

Руководство сложными системами

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

Если бы вы хотели испечь бисквитный торт, мы могли бы дать вам четкий рецепт. Рассказали бы, сколько нужно муки и яиц, какую температуру устанавливать в духовке. Мы даже могли бы объяснить, как проверить готовность бисквита. Выпечка достаточно маловариативна. Ингредиенты всегда одинаковы, вне зависимости от того, где вы их купите. Духовки запрограммированы на выпекание при определенных стандартных температурах. Самое главное, цель одна и та же — торт определенного вида.

Но вы не печете торты, а эта книга — не кулинарная. Так что придется разбираться с невероятным количеством вариантов. Например, у вас будут сотрудники с разным уровнем способностей к принятию решений. Регулирующие ограничения будут уникальными для вашей отрасли и местоположения. Вам предстоит обслуживать собственный динамично меняющийся клиентский рынок с его особой потребительской культурой. И в придачу ко всему ваши организационные цели и стратегии будут полностью уникальны.

Из-за всей этой изменчивости сложно прописать единственный правильный «рецепт» руководства API. Осложняющим фактором является эффект неожиданных последствий. Каждый раз, когда вы вводите правило, создаете новый стандарт или применяете какую-то форму руководства, вам придется иметь дело с такими последствиями. Так происходит потому, что все части организации взаимосвязаны.

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

Зная это, вы могли бы предсказать и предотвратить такие последствия. Но это невозможно сделать для каждой отдельной ситуации, особенно за короткое время. Вместо этого примите тот факт, что вы работаете со сложной адаптивной системой. И это не проблема, а просто особенность. Следует понять, как воспользоваться этим с выгодой для себя.

Сложная адаптивная система

Говоря о сложной адаптивной системе, мы подразумеваем следующее:

• в ней много взаимозависимых элементов, например люди, технологии, процессы, культура производства;

• составляющие могут динамически менять свое поведение и адаптироваться к системным изменениям (например, команды меняют методы развертывания при внедрении контейнеризации).

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

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

Обычно, говоря о системах в технологиях, подразумевают программные системы и сетевую архитектуру. Такие системы могут усложняться со временем. Интернет — идеальный пример сложности и эмерджентности7. Отдельные серверы в сети работают независимо друг от друга, но благодаря их взаимосвязям появляется нечто целое, называемое интернетом. Но бльшая часть ПО неадаптивна.

Интерфейсы API — не исключение. API, которые мы пишем сегодня, не очень адаптивны. Если они хороши, они делают именно то, на что их запрограммировали. После выпуска API вряд ли что-то изменится в его работе, если только кто-то не исправит его. Основная истина о руководстве API в том, что только оно не продвинет вас далеко. Вместо этого вам нужно управлять людьми в своей организации и решениями, которые они принимают в отношении API. Единственный способ получить лучшие API — это помочь вашим сотрудникам принимать полезные решения по API.

Люди хорошо приспосабливаются, особенно в сравнении с программным обес­печением. Ваша организация API — сложная адаптивная система. Все люди в ней принимают множество локальных решений: какие-то из них коллективно, а какие-то индивидуально. Когда таких решений много и принимаются они уже долго, система прогрессирует. Она, как и ваше тело, может адаптироваться ко многим изменениям.

Но управление решениями людей требует особого подхода. Влияние изменений на сложную систему трудно предсказать — изменения в одной части вашей организации могут привести к неожиданным последствиям в другой. Так происходит потому, что сотрудники постоянно адаптируются к изменениям среды. Например, введение правила, запрещающего развертывание программного обес­печения в контейнерах, имело бы далеко идущие последствия, влияющие на разработку ПО, наем, процессы развертывания и культуру.

Все это означает, что масштабный подход к управлению API с предварительным планированием и выполнением вряд ли сработает. Вместо этого вам нужно «подтолкнуть» систему, внеся небольшие изменения и оценив их влияние. Для этого нужны постоянные корректировки и улучшения, так же как при уходе за садом приходится обрезать ветки, сеять семена, поливать, постоянно наблюдая и подстраивая свои нынешние действия под результат предыдущих. В главе 5 мы детальнее разберем концепцию постоянного улучшения.

Управление решениями

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

Рассмотрим вымышленный пример руководства дизайном API в двух разных компаниях.

• Компания Pendant Software.Всем API-командам дается доступ к электронной книге Pendant Guidelines for API Design («Указания Pendant по разработке API»). Эти указания публикуются ежеквартально Центром по высокому качеству и передаче опыта в API компании Pendant — небольшой командой экспертов по API, работающих в этой компании. В них можно найти очень четкие правила разработки API. От всех команд ожидается неукоснительное выполнение указаний, а API перед публикацией автоматически тестируются на соответствие им.

В результате такой политики компания Pendant смогла опубликовать ряд ведущих в своей области и согласованных API, которые высоко оценили другие разработчики. Эти API помогли Pendant выделиться среди конкурентов на рынке.

• Компания Vandelay Insurance.Командам API сообщаются бизнес-цели компании и ожидаемые результаты для их продуктов. Эти цели и результаты определяются исполнительными командами и регулярно обновляются. У каждой команды API есть возможность достигать общей бизнес-цели любым выбранным способом. Несколько команд могут выбрать одну и ту же цель. API-команды могут разрабатывать и реализовывать API как им угодно, но каждый продукт должен соответствовать параметрам и стандартам отслеживания компании Vandelay. Стандарты определяются Системным обществом Vandelay — группой, состоящей из участников каждой команды API, которые вступают в нее добровольно и определяют общепринятый набор стандартов.

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

В наших вымышленных исследованиях и Pendant, и Vandelay очень эффективно управляли принятием решений. Но руководили они этой работой по-разному. Компания Pendant пришла к успеху с помощью высокоцентрализованного авторитарного подхода, а Vandelay предпочла метод ориентирования на результат. Здесь нет единственно верного подхода, у обоих стилей руководства есть свои преимущества.

Для эффективного руководства принятием решений ответьте на три важных вопроса.

• Какими решениями управлять?

• Кто и где должен принимать эти решения?

• Как стратегия управления решениями повлияет на систему?

В системе с поддержкой API необходимо принять множество решений, как на уровне API, так и на коллективном, «ландшафтном» уровне. Мы рассмотрим весь спектр решений, которые нужно принимать и которыми необходимо управлять, в главах 4 и 9.

А пока сосредоточимся на втором вопросе: где в системе должны приниматься самые важные решения? Чтобы помочь вам в этом разобраться, углубимся в тему управления решениями. Мы займемся поиском компромисса между централизованным и децентрализованным принятием решений и подробнее рассмотрим, что значит распределять решения.

Централизация и децентрализация

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

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

Как мы уже говорили, ваша организация — это тоже сложная адаптивная система. Она — продукт всех индивидуальных решений сотрудников. Как и в случае с чело­веческим телом или экосистемой пруда, если бы вы предоставили работникам полную автономию, организация в целом стала бы более устойчивой и адаптивной. Вы получите децентрализованную компанию без начальника, способную выжить благодаря индивидуальным решениям сотрудников (рис. 2.1).

Рис. 2.1. Децентрализованная организация

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

Но руководители предприятий плохо реагируют на такой уровень неопределенности и отсутствия контроля. Скорее всего, вам нужно будет направить свою систему на конкретные цели, выходящие за рамки выживания. Кроме того, вы вряд ли захотите допустить ликвидацию компании ради того, чтобы ее место заняла другая, более успешная. И практически точно вы хотите уменьшить риск разрушения всей компании из-за неудачного решения одного сотрудника. Поэтому нужно урезать свободу принятия индивидуальных решений и ввести какую-то отчетность. Один из способов сделать это — централизация решений (рис. 2.2).

Рис. 2.2. Централизованная организация

Здесь подразумевается, что в организации принятие решений поручено конкретным человеку или команде. Эта централизованная группа принимает решение, которое должны исполнять остальные. Децентрализация означает обратное: отдельные команды могут принимать решения, которые обязаны выполнять только они.

В реальности только централизованных или децентрализованных организаций нет. Разные типы решений распределяются в организации по-разному: одни более централизованно, другие менее. Вам придется позаботиться о том, как распределять решения, влияющие на систему сильнее всего. Так какие из них должны быть более централизованными?

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

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

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

• Затраты на координацию.Нельзя своевременно принять сложное решение, если процесс не будет коллективным. Но в этом случае придется учесть затраты на координацию. Если они слишком вырастут, вы не сможете быстро принимать решения. Централизация и децентрализация решений могут очень серьезно влиять на эти затраты.

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

Масштаб оптимизации

Централизованное и децентрализованное решения сильно различаются по своему масштабу. Централизованное решение принимается для целой организации. Объем оптимизации в этом случае включает в себя всю систему, и ваша цель — принять решение, которое ее улучшит. Иначе говоря, это решение должно оптимизировать объем системы. Например, централизованная команда может выбрать методологию разработки, которой будет следовать вся компания. Та же команда может выбрать API, который нужно удалить. Оба решения должны быть приняты с учетом выгоды для всей системы.

И наоборот, суть децентрализованного решения в том, что оно оптимизировано для локального масштаба. В этом случае вы принимаете решение, которое улучшит частности — информацию, которая относится только к конкретной ситуации. Хотя ваше решение может повлиять на систему в целом, ваша цель — улучшить свои локальные результаты. Например, команда API может принять решение использовать каскадный процесс разработки, потому что она работает совместно с внешней компанией, которая на этом настаивает.

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