Книжный куб

Глава "API Governance" из книги API Management - Part II (Рубрика #Management)

Продолжая рассказ из прошлого поста, обсудим как можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода. Для этого стоит разделить процесс принятия решений на отдельные этапы, которые похожи на пайплан разработки:) И эти этапы следующие
1. Inception (начало). Каждое решение принимается, потому что кто-то считает, что это решение необходимо принять. Это означает, что кто-то определил, что проблема или возможность существуют с более чем одним возможным решением.
2. Choice generation (генерация опций). Если вы принимаете решение в области, в которой у вас большой опыт, генерирование вариантов может быть довольно простым. Но если есть много неизвестных, вам нужно будет потратить больше времени на определение возможностей.
3. Selection (выбор). Это сердце принятия решения, на котором большинство людей фокусируется, но важность элемента выбора во многом зависит от объема доступных вариантов.
4. Authorization (авторизация принятого решения). Тот факт, что выбор был сделан, не означает, что решение принято. Выбор должен быть авторизован, прежде чем он может быть реализован. Авторизация — это работа по принятию решения о действительности выбранного выбора. Был ли сделан правильный выбор? Осуществим ли он? Безопасен ли он? Имеет ли он смысл в контексте других принятых решений?
5. Implementation (реализация). Процесс принятия решения не заканчивается, когда выбор авторизован. Реализация является важной частью работы по управлению API. Если реализация решений происходит слишком медленно или некачественно, то все ваши решения напрасны.
6. Challenge (оспаривание). Решения не являются неизменными, и каждое решение, которое вы принимаете для вашей системы управления API, должно быть открыто для оспаривания. Часто мы не думаем о том, что принимаемые нами решения могут потребовать пересмотра, изменения или даже отмены в будущем. Определение элемента вызова позволяет нам планировать непрерывные изменения на уровне принятия решений.

И вся прелесть в том, что можно централизовать или децентролизовать каждый из шагов этого подхода к принятию решений. Наприме, при выборе языка для разработки: Inception - centralized, choice generation - centralized, остальное decentralized. Тут суть в том, что централизованно определяются доступные языки, а команды децентрализованно сами решают на каком из них писать.

Авторы отмечаютют, что хорошие governance системы должны включать следующие фичи
- Распределение решений на основе impact, scope, and scale (про это было в первом посте)
- Enforcement системных органичений и валидация имплементации (для централизованных решений)
- Incentivization для формаирования принятия решений (для децентрализованных решений)
- Адаптивность измерения импакта и постоянных улучшений

Продолжение в последнем посте из этой серии, где мы поговорим про паттерны организации governance процессов.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Telegram

Книжный куб

Глава "API Governance" из книги API Management - Part I (Рубрика #Management)

Я уже дедал краткое саммари отличной книге "API Management", но сегодня хотел кратенько рассказать о главе про governance, читая которую я ловил очень много флешбеков:)
Основные…

www.tgoop.com/book_cube/3006

2.2K viewsAlexander Polomodov, edited  Jan 17 at 17:20

Глава "API Governance" из книги API Management - Part II (Рубрика #Management)

Продолжая рассказ из прошлого поста, обсудим как можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода. Для этого стоит разделить процесс принятия решений на отдельные этапы, которые похожи на пайплан разработки:) И эти этапы следующие
1. Inception (начало). Каждое решение принимается, потому что кто-то считает, что это решение необходимо принять. Это означает, что кто-то определил, что проблема или возможность существуют с более чем одним возможным решением.
2. Choice generation (генерация опций). Если вы принимаете решение в области, в которой у вас большой опыт, генерирование вариантов может быть довольно простым. Но если есть много неизвестных, вам нужно будет потратить больше времени на определение возможностей.
3. Selection (выбор). Это сердце принятия решения, на котором большинство людей фокусируется, но важность элемента выбора во многом зависит от объема доступных вариантов.
4. Authorization (авторизация принятого решения). Тот факт, что выбор был сделан, не означает, что решение принято. Выбор должен быть авторизован, прежде чем он может быть реализован. Авторизация — это работа по принятию решения о действительности выбранного выбора. Был ли сделан правильный выбор? Осуществим ли он? Безопасен ли он? Имеет ли он смысл в контексте других принятых решений?
5. Implementation (реализация). Процесс принятия решения не заканчивается, когда выбор авторизован. Реализация является важной частью работы по управлению API. Если реализация решений происходит слишком медленно или некачественно, то все ваши решения напрасны.
6. Challenge (оспаривание). Решения не являются неизменными, и каждое решение, которое вы принимаете для вашей системы управления API, должно быть открыто для оспаривания. Часто мы не думаем о том, что принимаемые нами решения могут потребовать пересмотра, изменения или даже отмены в будущем. Определение элемента вызова позволяет нам планировать непрерывные изменения на уровне принятия решений.

И вся прелесть в том, что можно централизовать или децентролизовать каждый из шагов этого подхода к принятию решений. Наприме, при выборе языка для разработки: Inception - centralized, choice generation - centralized, остальное decentralized. Тут суть в том, что централизованно определяются доступные языки, а команды децентрализованно сами решают на каком из них писать.

Авторы отмечаютют, что хорошие governance системы должны включать следующие фичи
- Распределение решений на основе impact, scope, and scale (про это было в первом посте)
- Enforcement системных органичений и валидация имплементации (для централизованных решений)
- Incentivization для формаирования принятия решений (для децентрализованных решений)
- Адаптивность измерения импакта и постоянных улучшений

Продолжение в последнем посте из этой серии, где мы поговорим про паттерны организации governance процессов.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

BY Книжный куб