Тем не менее ряду предприятий не удалось получить ожидаемые выгоды от API. Во многих случаях создание API без продуманной стратегии создает беспорядок с дублированием разработок, с плохим обслуживанием и ограниченной прозрачностью, сводя на нет многие из потенциальных преимуществ интерфейсов. Некоторые компании потратили годы на замену мегасистем, на добавление API-интерфейсов не имея соответствующих стратегии и плана. И, соответственно, такие компании не сумели достичь реального прогресса.
Можно привести ряд причин таких неудач. Например, ИТ-отдел принимает единоличные решения в части владения программами API и не имеет тесной связи с бизнес-целями или с общим видением модернизации. Итог - сбой. Другая причина сбоя - разрозненные усилия. Например, сосредоточенность исключительно на данных или на миграции приложений и данных в облако.
Компании часто используют множество разных и неподходящих показателей для оценки производительности API. Действия команд следует оценивать с использованием набора общих гибких метрик: прямая бизнес-ценность API-интерфейсов, ориентированных на клиентов, и повторное использование/сокращение "технической задолженности" для API-интерфейсов серверной части. Другие потенциальные метрики включают одобрение API разработчиками, вклад в упрощение архитектуры или снижение затрат на инфраструктуру и ключевые показатели эффективности (KPI) для конкретных случаев.
Общие метрики.
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 будут создаваться, и кто платит за их разработку - важный и порой спорный вопрос. В некоторых организациях функциональные подразделения определяют и оплачивают создание API, ориентированные на клиентов, а технологическая группа создает их. Это хорошо работает, когда уже существует "цифровая" стратегия. Однако некоторые организации находятся в процессе разработки цифровой стратегии и не готовы к масштабному созданию клиентских API. В таком случае ИТ-группа должна управлять и финансировать создание клиентских API и системных API нижнего уровня.
Лучшей практикой является совместное владение API-интерфейсами, особенно когда межфункциональные цифровые команды создают API-интерфейсы взаимодействия с клиентами. В подобных случаях бизнес-подразделения владеют и платят за API-интерфейсы взаимодействия, в то время как технологическая группа владеет API-интерфейсами процессов и систем нижней части стека.
Во всех случаях некоторая структура должна контролировать портфель API на протяжении всего их жизненного цикла. Данная структура часто состоит исключительно из ИТ-персонала, но в нее также должны входить представители бизнеса. Структура следит за производительностью API и решает, какие новые API нужно добавить, а какие закрыть. Это подразделение также наблюдает за финансированием проектов API, изменяет приоритеты проектов, поощряет повторное использование API.
Гибкий жизненный цикл API непрерывного улучшения
Анализ потребностей в API.
Есть два набора решений, которые компании должны принять в отношении квалификации.
1. Какие приобрести новые навыки.
Компании, приступающие к реализации программы API, обычно нуждаются в опытных специалистах-практиках, обладающих опытом преобразования существующей инфраструктуры с поддержкой API. Это означает привлечение экспертов, которые могут получить доступ к монолитным ядрам с помощью микросервисов, используя инструменты с открытым исходным кодом. Эти эксперты должны быть знакомы с процессами DevOps для API, а также уметь реализовывать стратегию разработку API, выполнять действия по обслуживанию в течении всего жизненного цикла API. Крайне важно иметь в штате специалистов-практиков, обладающих такими навыками, поскольку они составляют основу подхода к API в компании и нуждаются в тесном сотрудничестве с существующими руководителями ИТ и бизнеса.
2. Какие технологические внутренние возможности улучшить или создать
Для создания новых бизнес-возможностей необходимо информировать бизнес-лидеров о ценности API и повышать квалификацию ИТ-архитекторов и разработчиков, чтобы они могли работать в современной среде разработки API. Руководители бизнеса должны понимать "что такое API-интерфейс" и варианты его использования, какие требуются ресурсы для разработки, развертывания и эксплуатации API прежде всего для получения полной ценности от использования API. ИТ-архитекторы и разработчики должны хорошо разбираться в различных типах API-интерфейсов, которые потребуются и изучать современные технологии. Они также должны получить возможность пользоваться основными инструментами и средами разработки API.
Можно привести ряд причин таких неудач. Например, ИТ-отдел принимает единоличные решения в части владения программами API и не имеет тесной связи с бизнес-целями или с общим видением модернизации. Итог - сбой. Другая причина сбоя - разрозненные усилия. Например, сосредоточенность исключительно на данных или на миграции приложений и данных в облако.
Чтобы избежать ловушек и получить выгоды от инициатив в области API, ИТ-директора должны решить семь ключевых задач.
Задача №1. С чего начать?
Задача актуальна в том случае, если непонятно - какие первые шаги в деле создания и реализации 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, который гарантирует то, что команды следуют техническим стандартам и передовым методам, и создаваемый продукт согласуется с архитектурным видением ИТ - конечным состоянием, предполагаемым после завершения программы технической модернизации.
- Доступ к данным и интеграция. API-интерфейсы могут предоставлять данные в различных ИТ-системах, как в устаревших, так и в современных. Затем их можно использовать для извлечения данных и связывания их с системами расширенной аналитики.
- Миграция в облако. Большинство крупных организаций по-прежнему имеют значительную внутреннюю локальную инфраструктуру и только начали переходить на частные облака. Небольшое количество компаний приступает к миграции в публичное облако. Управление гибридной облачной средой требует от ИТ-руководителей API-интерфейсов, которые могут получить доступ к инфраструктуре как в частных, так и в общедоступных облачных активах.
- Базовая цифровая трансформация. API-интерфейсы могут помочь в преобразованиях, поскольку они могут подключать основные ИТ-системы и конкретные данные внутри них к цифровым платформам. API-интерфейсы также могут служить соединительной тканью и механизмом синхронизации как в современных, так и в устаревших системах.
Все элементы тесно связаны. Таким образом, чтобы определиться с первоочередными API-интерфейсами, необходимо составить список наиболее важных задач. Затем отметить - какие API-интерфейсы способствуют решению этих задач. Тем самым, реализация этих API-интерфейсов позволяет разблокировать данные, облако и ресурсы, способствующие решению важных задач. Второе, определить API-интерфейсы, которые позволят организации работать гибко и продуктивно, в частности, работать в раъных режимах, - в режиме продуктивной эксплуатации, в режиме тестирования и обучения.
Задача №2. Как должны выглядеть команды разработки и внедрения API?
Команды, создающие API, должны использовать гибкую операционную модель. Для этого необходимо отказаться от рассмотрения создания API как набора разовых проектов и вместо этого рассматривать каждый API как продукт, который со временем будет развиваться и улучшаться на основе откликов и отзывов клиентов. Два основных элемента - это команды с нужным набором навыков и организационная структура, которая поддерживает бизнес-потребности компании.
Команды API нуждаются в потребителе и во владельце продукта, что гарантирует того, что создаются нужные и поэтому ценные API. Также нужен архитектор API, который гарантирует то, что команды следуют техническим стандартам и передовым методам, и создаваемый продукт согласуется с архитектурным видением ИТ - конечным состоянием, предполагаемым после завершения программы технической модернизации.
Компании могут выбирать различные организационные структуры для управления разработкой API.
- Централизованный подход. Централизованная группа разрабатывает большинство API как для бизнеса, так и для технологических подразделений. Эта модель позволяет быстро создавать множество API, но центральной группе необходимо тесно сотрудничать с бизнесом на местах или с ИТ-подразделениями с тем, чтобы обеспечить приоритетность разработки нужных API.
- Децентрализованный подход. Набор специализированных "мастерских" - групп разработки API, встроенных в различные бизнес-подразделения и в технологические подразделения. Этот подход работает как кросс-функциональный. В этой модели API-интерфейсы с большей вероятностью будут согласованы с бизнес-потребностями, но обеспечение соблюдения стандартов и передовых методов разработки может оказаться трудным.
- Гибридный подход. Согласно гибридной модели централизованная структура, - фабрика API, - создает базовые API. Отдельные бизнес-подразделения и технологические подразделения вносят свой вклад в каталог API, следуя таксономии и стандартам, установленным центральным ИТ-подразделением и использует базовые API, созданные центральным подразделением.
Задача № 3: Что отслеживается и как демонстрируются преимущества программы API?
Компании часто используют множество разных и неподходящих показателей для оценки производительности API. Действия команд следует оценивать с использованием набора общих гибких метрик: прямая бизнес-ценность API-интерфейсов, ориентированных на клиентов, и повторное использование/сокращение "технической задолженности" для API-интерфейсов серверной части. Другие потенциальные метрики включают одобрение API разработчиками, вклад в упрощение архитектуры или снижение затрат на инфраструктуру и ключевые показатели эффективности (KPI) для конкретных случаев.
Общие метрики.
Затраты.
- Затраты на разработку API: средние затраты на разработку АРI, опеределяемые путем деления бюджета на разработку API, приходящегося на рассматриваемое API.
- Затраты на выполнение API. Средние операционные затраты на API, включая поддержку и исправление ошибок, опеределяемые как операционные расходы, приходящиеся на API.
Качество.
- Количество инцендентов на API. Число ошибок, происходящих в ходе применения API.
- Качество кода. Количество ошибок, приходящихся на автоматически выполняемые тесты.
- Покрытие автоматизированными тестами. Определяется в ходе проведения тестирования.
Результативность.
- Количество реализованных АPI. Общее число используемых API.
- Количество активно используемых API. Процент API, встроенных в приложения.
Влияние сервисных API.
- Сокращение "технологической задолженности". Процент АPI, используемых в сервисных программах и программах разработки.
- Повторное использование API. Среднее число приложений и сервисов, в которые интегрированы API.
Влияние клиентских API.
- Монетизация. Доходы или прибыль, генерируемые API.
Задача №4. Какая бизнес-польза API-интерфейсов?
Повышают ли API-интерфейсы ценность и гибкость бизнеса?API-интерфейсы исторически классифицировались как промежуточное программное обеспечение, которое интегрирует данные и обменивается данными между несколькими системами. Поскольку большая часть усилий по API была сосредоточена в ИТ-группе, то систематика, используемая для их классификации, техническая и интуитивно непонятная. Это мешает заинтересованным сторонам от бизнеса участвовать в разработке API и в определении соответствующих приоритетов.
Решение состоит в том, чтобы различать API-интерфейсы, которые непосредственно обслуживают бизнес (где важен вклад в бизнес), и API-интерфейсы, которые являются техническими инструментами. Прочная таксономия позволяет бизнесменам разговаривать с ИТ-персоналом о том, какие API-интерфейсы напрямую влияют на качество обслуживания клиентов, а какие являются частью инфраструктуры.
Задача № 5: Какие технологические инструменты нужны?
ИТ-руководители могут легко потеряться в технологиях, связанных с API, что ведет к потере ресурсов и снижению производительности.
Первым ключевым техническим решением является выбор правильного фреймворка или платформы разработки приложений для создания API. Далее важно работать с руководителями бизнеса и иметь список надлежащих вариантов использования API-интерфейсов на основе технической осуществимости (например, готовности серверной части), бизнес-правил и условий, которые необходимо обрабатывать. Затем ИТ-организации необходимо установить форматы данных для API-интерфейсов и разработать эталонную архитектуру API, которая будет модульной, гибкой и расширяемой. Это предотвратит создание ненужных технических слоев. Руководители инженерных разработок также должны установить руководящие принципы разработки API, обучить владельцев продуктов лучшим практикам применения API, предоставлять наборы инструментов и каталоги API и следить, чтобы разработчики придерживались передовых практик и повторно использовали API.
Следующие технологическое решение касается шлюза и портала разработчика API. Шлюз API содержит все API, собирает аналитику в ходе выполнения транзакций и выполняет кэширование данных. Важно решить, кто управляет шлюзом, и установить правила управления им. Некоторые компании выбирают централизованную платформу API. Хотя для одной команды может быть полезно отвечать за шлюз, но эта команда может стать узким местом. Облачный API-шлюз и портал для разработчиков позволяют отдельным подразделениям отвечать за разные наборы API, а также позволяют разработчикам получать доступ ко всем API в одном месте. Это обеспечивает децентрализованное управление на основе ряда опубликованных стандартов, которые применяются в организации.
При принятии решения о привлечении или аутсорсинге разработки API следует руководствоваться практическим правилом: API-интерфейсы должны принадлежать и храниться внутри компании, если они могут создавать отличительные возможности для компании. API, которые не позволяют дифференцировать практики применения, лучше приобретать.
Проблема № 6: Кому и какие 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.
- Поддержка проектных команд, использующих API.
- Мониторинг во время работы:
- Безопасность.
- Применение.
- Ценность для бизнеса.
- Измерение и регулирование.
Обзор производительности API.
- Рассмотрение каждого спринта, API метрик для определения последующих шагов (продолжение операций, модификаций или вывода из эксплуатации).
- Извлечение уроков из мониторинга.
- Потребность новых модификаций в рамках действующих жизненных циклов.
Вывод API из эксплуатации.
- Вывод устаревщих API.
В рамках своей работы ИТ комитет должен заняться внедрением API. Это означает, что любой проект API должен иметь четкий план внедрения для утверждения. Это очень важно, чтобы избежать ловушки «построй, и пользователи появятся». Планы внедрения должны разрабатываться бизнес-группами и маркетинговыми группами, работающими в тесном сотрудничестве с ИТ. API-интерфейсы самообслуживания, которые будут доступны для внешних клиентов или партнеров, должны соответствовать соответствующим техническим, юридическим и маркетинговым спецификациям, а также быть простыми в использовании. Внутренние API-интерфейсы должны быть документированы и доступны внутри организации.
Задача № 7: Определиться - откуда взять достаточно квалифицированных сотрудников?
Есть два набора решений, которые компании должны принять в отношении квалификации.
1. Какие приобрести новые навыки.
Компании, приступающие к реализации программы API, обычно нуждаются в опытных специалистах-практиках, обладающих опытом преобразования существующей инфраструктуры с поддержкой API. Это означает привлечение экспертов, которые могут получить доступ к монолитным ядрам с помощью микросервисов, используя инструменты с открытым исходным кодом. Эти эксперты должны быть знакомы с процессами DevOps для API, а также уметь реализовывать стратегию разработку API, выполнять действия по обслуживанию в течении всего жизненного цикла API. Крайне важно иметь в штате специалистов-практиков, обладающих такими навыками, поскольку они составляют основу подхода к API в компании и нуждаются в тесном сотрудничестве с существующими руководителями ИТ и бизнеса.
2. Какие технологические внутренние возможности улучшить или создать
Для создания новых бизнес-возможностей необходимо информировать бизнес-лидеров о ценности API и повышать квалификацию ИТ-архитекторов и разработчиков, чтобы они могли работать в современной среде разработки API. Руководители бизнеса должны понимать "что такое API-интерфейс" и варианты его использования, какие требуются ресурсы для разработки, развертывания и эксплуатации API прежде всего для получения полной ценности от использования API. ИТ-архитекторы и разработчики должны хорошо разбираться в различных типах API-интерфейсов, которые потребуются и изучать современные технологии. Они также должны получить возможность пользоваться основными инструментами и средами разработки API.
Данный материал изложен в
Комментариев нет:
Отправить комментарий