Глава "API Governance" из книги API Management - Part I (Рубрика Management)
Я уже дедал краткое саммари отличной книге "API Management", но сегодня хотел кратенько рассказать о главе про governance, читая которую я ловил очень много флешбеков:) Основные мысли, что я извлек для себя примерно такие
- Слово "governance" нравится не всем, поэтому иногда его лучше не использовать, но авторы говорят, что
In fact, we’ll go as far as saying that it’s impossible to manage your APIs without governing them. Поэтому тот или иной подход к governance существует и авторы предлагают модель для осмысленного выбора подхода
- Этими элементами системы governance являются: decisions, management, complexity
- Инженерная работа предполагает большое количество решений, причем часть решений влияют на то, как себя будет чувствовать в дальнейшем бизнес
- В большой компании может требоваться принимать много решений и в ограниченный промежуток времени, а governance должен помогать в организации процесса принятия этих решений так, чтобы они были качественными.
- Процессы governance - это дорогое удовольствие, но хорошая новость в том, что не требуется контролировать все принимаемые решения в организации, а плохая в том, что надо определиться с тем, а что нужно контролировать для получения хороших результатов
- Здесь вступает в дело complexity, а точнее то, что мы работаем с complex adaptive system, у которых следующие интересные свойства
- В них много взаимозависимых частей (люди, технологии, процессы, культура, ...)
- Эти части меняют свое поведение динамически и адаптируются к изменениям (например, изменения в технологиях инфры приводить к изменению практик развертывания)
- Люди хорошо адаптируются к изменениям в отличие от нашего существующего софта и они умеют принимать локально оптимальные решения, из которых вырастает со временем большая система
- Если мы хотим влиять на поведение людей и принятие ими решений в нужную нам сторону, то мы не можем рубить с плеча и вот, что авторы книги рекомендуют делать
A big, up-front plan and execution approach to API governance is unlikely to work. Instead, you’ll need to “nudge” the system by making smaller changes and assessing their impact. It requires an approach of continuous adjustment and improvement, in the same way you might tend to a garden, pruning branches, planting seeds, and watering while continuously observing and adjusting your approach.
- Для эффективного управления принятием решений стоит ответить на три вопроса
- Какие решения надо менеджерить?
- Кто и где должен принимать эти решения?
- Как эта стратегия принятия решений повлияет на CAS (complex adaptive systems)
- Вообще есть 2 концептуальных способа принятия решений: централизованный и децентрализованный. Их проще всего рассматривать через призму трех факторов
- Доступность и точность информации для принятия решений
- Талант к принятию решений
- Стоимость координации
- Другие важные аспекты для рассмотрения - это scope и scale
- Scope of optimization - условно при децентрализованном принятии решений могут приниматься локально оптимальные решения и все будет выглядеть модно и инновационно. Но если учитывать только local scope, то на всю систему решения могут влиять негативно - дружить эти отдельные решения на уровне всей компании будет ой как тяжело
- Scale of operations - это про количество решений, которые требуется принять. Условно, если требуется принимать сложные решения, то сложно обеспечить все децентрализованные команды профессионалами, что смогут их принять. А централизация принятия решений приведет центральную группу в бутылочное горлышко.
Казалось бы, мы в тупике, но оказывается, что можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода, но об этом в следующем посте.
#Architecture #Software #Governance #Management #Leadership #Processes #Leadership