Обзор whitepaper "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (Рубрика #Architecture)

Недавно я прочитал очень интересное исследование на тему API Governance от академических исследователей и специалистов из Google. Целью исследования было понимание влияния подходов к управлению API (application programming interface) на продуктивность и usability. По итогам этого research исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API. Мне это исследование показалось интересным для написания обзора, так как последние годы я имею отношение на работе к темам
- Architecture governance
- Development productivity
- API management
А этот whitepaper имеет отношение к каждой из этих тем:)

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

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

Подробнее про этот whitepaper можно почитать в моей статье

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Governance at Scale (Рубрика #Management)

Недавно прочитал интересную статью исследователей про API Governance процессы в Google. На самом деле эта статья напрямую предшествует статье "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency", про которую я рассказывал раньше. В статье "API Governance at Scale" авторы в деталях как и зачем авторы меняли подход к построению API. Собственно, они пришли к процессу, что состоит их трех частей
1) API Improvement Proposals - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API
2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере)
3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше

Это исследование рассматривает этот процесс со стороны создателей API и показывает позитивное влияние на качество API как со стороны результата, так и процесса. Интересно, что в уже упомянутой статье-продолжении "AI-Enhanced API Design" этот же процесс рассматривается как со стороны создателей, так и потребителей API и тоже показывает положительное влияние.

В общем, whitepaper интересный и я точно сделаю его более подробный разбор, но рекомендую почитать статью в оригинале - она короткая, но очень интересная:)

P.S.
Именно странички из этой статьи послужили иллюстрацией к посту про whitepaper.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Improvement Proposals (Рубрика #Architecture)

Я уже рассказывал про whitepaper "API Governance at Scale", по которому скоро будет обзорная статья, а потом еще и выпуск нового подкаста с обзорами whitepaper. Но сегодня я хотел бы рассказать, что у ребят есть публичные артефакты, которые доступны для изучения всем заинтересованным людям
1) API Improvement Proposals (AIPs) - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API. Эти AIPs разбиты по следующим категориям: meta, process, API concepts, resource design, operations, fields, design patterns, compatibility, polish, protocol buffers. Их очень интересно изучить
2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере). Он работает только для API, определенных с помощью protocol buffers.
3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше. Но публичного это процесса нет:)

Отдельно авторы описали как можно внедрить этот процесс у себя "Adopting AIPs in your company" (еще рекомендую почитать Github)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

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

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

What Is Your Definition of Software Architecture (Рубрика #Architecture)

Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру
- Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов
- Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership"
- Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства
- Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта
- Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями
- Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns"
- Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений.

В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:)
Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance #ArchBook

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)

Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)

1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам

2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).

3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.

В общем, книги достойные - я получил большое удовольствие, когда их изучал:)

#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API