Платформенный подход и трансакционные издержки

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

Подробнее предлагаю прочитать в википедии, либо в первоисточнике — я мог недостаточно четко пересказать основные мысли оттуда.

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

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

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

Либо команды должны быть горизонтальными, с максимально полностью делегированной ответственностью за сквозной Value Stream — для оптимизации команды вокруг пропорции “доставляемая до клиента ценность к running cost” этого стрима. При этом, чтобы не было роста управленческих издержек внутри команды вся непрофильная активность этого стрима будет аутсорситься на внешних вендоров (по отношению к команде, не к компании!), т.е. на платформенные и развивающие (enabling) команды.

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

Чего не хватает в этой картине? Финансирования, т.е. циклов обратной связи между платформенной командой и “внутренним рынком”, и горизонтальной командой (но не компанией целиком!) и “внешним рынком”. Какие-то зачатки такой обратной связи предлагаются в практиках “error budget” и “security budget” и абстрактных отсылках к “продуктовому подходу” без конкретики, но их явно недостаточно.

Встречались ли кому-то еще какие-то материалы на эту тему?

Об формальные и неформальные нотации

Если сравнивать "просто стикеры" в миро и Archimate, то Archimate удобнее тем, что мы в нем получаем "встроенную" валидацию типов, которую в случае стикеров приходится выполнять более явно.

Скорее всего это применимо и для других формальных языков описаний (BPMN, UML и т.д.) в сравнении со "свободными" рассуждениями.

С другой стороны, если понимания типов у человека нет все нотации мгновенно становятся бессмысленными.
А для коммуникации нужны именно типы, пространство понятий, а не нотация.

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

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

Или это не так?

В понедельник на конференции DevOpsConf буду рассказывать про применение практик из разработки в подходе Infrastructure as Code

Написал новую статью "Об Модифицирующие Команды".

Как обычно, кросспост в несколько мест:
- https://habr.com/ru/post/723410/
- https://timurbatyrshin.medium.com/41db803e1875
- https://timurb.ru/kb/ob-enabling-team/

Написал новую статью "Ситуационная инженерия метода".

Длинные посты в телеграм не влезают, поэтому как обычно, только кросспост в несколько мест:
- https://timurbatyrshin.medium.com/1b9f246a1cd9
- https://timurb.ru/kb/situational-method-engineering/

Комментарии можно оставлять как здесь, так и по любой из ссылок.

Друзья, для меня очень ценна обратная связь. Если для вас что-то кажется спорным, прошу: пишите текстом.
Можно личным сообщением (@TimurBatyrshin) если не хотите выносить в общий чат.

Об разницу между Waterfall и Agile
(из неопубликованных архивов)

Некоторое время назад нашел простое и потрясающее объяснение того, когда нужно выбирать waterfall, когда scrum, а когда еще что-то другое.

Цитата (отсюда https://sebokwiki.org/wiki/System_Lifecycle_Models):
There are a large number of potential life cycle process models. They fall into three major categories:
1. primarily pre-specified and sequential processes (e.g. the single-step waterfall model)
2. primarily evolutionary and concurrent processes (e.g. lean development, the agile unified process, and various forms of the vee and spiral models)
3. primarily interpersonal and emergent processes (e.g. agile development, scrum, extreme programming (XP), the dynamic system development method, and innovation-based processes)

Перевожу на простой человеческий язык:
1. Если вам нужно строить что-то ровно один раз, без параллелизации работ, или доработок вообще, или же нужен жесткий процесс с контролем выходов на каждой стадии — waterfall ваш выбор.
2. Если вам нужно разрабатывать несколько фич параллельно, или процесс будет дорабатываться (но сам процесс есть) — выбирайте второй вариант.
3. Если вы выясните процесс работы по ходу в процессе личного взаимодействия — выбирайте третий вариант.

Казалось бы, где тут откровения? Но давайте представим, какие последствия будут при выборе каждого из вариантов.
1. Waterfall: Пока пилим фичи баги исправлять не будем (и наоборот). Если потребуется в процессе внести какие-то изменения это будет очень тяжело.
2. Эволюционные/параллельные процессы: Нужно прописать и как-то контролировать процесс работы, и как дорабатывать его самого. Нужно определить как нам не мешать друг другу при параллельной разработке.
3. Межличностные и эмерджентные процессы: Ребята у нас умные, как-нибудь сами обо всем договорятся. В том числе и с заказчиками и внешними стейкхолдерами (спонсор, регуляторы, команды-смежники, внешние провайдеры, в т.ч. коммерческие и т.д.).

Какой из вариантов лучше всего подходит к вашему проекту?

Об гиперпространственные тоннели между деятельностными мирами

Меня очень вдохновляет язык моделирования Archimate (https://www.cfin.ru/itm/EA_ArchiMate.shtml) при всех его недостатках. Я не особенно задумывался почему -- на нем удобно отображать связи и взаимодействие между людьми, процессами, приложениями, технологиями, но кажется этого недостаточно чтобы служить вдохновением.
Сегодня я понял в чем дело: за счет его метамодели у нас в рассуждениях появляется интерфейс, связывающий между собой понятия из самых разных областей.

Метамодель Archimate очень простая, это формула "cубъект -- выполняет действия -- с объектом", и в дополнение представление ее же во внешний мир в виде сервисов и интерфейсов.

Что здесь примечательно, так это то, что мы можем за счет этого одновременно описывать несколько миров: мир практик и отношений между практиками, мир субъектов и их должностей, и мир объектов и их использования. Фактически эта формула выступает неким гиперпространственным тоннелем, который позволяет нам мгновенно переходить между рассуждениями в каждом из этих миров и связывать между собой факты, которые внешне никак не связаны.
Если Вася -- столяр, а столяр выполняет практику "изготовление табуретки", и в ее процессе превращает древесину в табуретку, то мы через эту формулу можем легко отследить, что Вася превращает древесину в табуретку. Это для известных доменов знаний звучит просто, но для неизвестной области это не так: сможете ли вы утверждать, каким образом при помощи бубузятора получаются хрямзики и что еще для этого нужно? Только через определение процесса получения хрямзиков, указание его входов, выходов, роли исполняющей этот процесс и через назначение бубузятора роль выполняющую этот процесс.

В дополнение к этому деятельностному гиперпространственному тонелю Archimate вводит еще несколько таких гиперпространственных тоннелей, связывающих между собой пространство предприятия (бизнес-процессы и бизнес-функции, исполнители, ответственные лица, материальные активы), пространство ИТ-приложений (ИТ-компоненты, объекты данных, программные процессы), пространство технологий (артефакты, узлы, сети) и дополнительные пространства для обсуждения мотивации, стратегии и проектной деятельности.

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

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

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

В ISO 42010 / ГОСТ Р 57100 точки входа в такие тоннели называются Architecture Viewpoint.
Описываются они в стандартах и нотациях моделирования.
Если их освоить и гармонизировать между собой появляется возможность быстро путешествовать в любую точку мира.

Во вторник, 5 марта, на конференции DevOpsConf делаю доклад для инженеров и начинающих тимлидов о том как подключаться к новым проектам.
Если вы вдруг хотите купить билет, но почему-то этого еще не сделали, у меня для вас есть промокод на скидку 7%: DevOpsMoscow_2024
https://devopsconf.io/moscow/2024/abstracts/11628

Экспериментирую с пропусканием текстов через ChatGPT и последующей доработкой напильником

"Цель DevOps — это переход от документоориентированных (document-centric) процессов управления разработкой ПО и процессов управления IT-сервисами к кодоориентированным (software-defined).
При этом методы управления всеми этими процессами могут быть различными — как использование единого инструмента для оркестрации всех процессов и активностей, так и интеграция различных инструментов и сервисов в единую распределенную систему."

Выложили видео моего доклада на конференции DevOpsConf, которая происходила 4 и 5 марта 2024г.

Я делал доклад для инженеров и начинающих лидов — о том как ускорить свою производительность и снизить количество возникающих пожаров.

Ключевые слова: GTD, Meeting notes, Decision records

Поделитесь с теми ребятами у себя в команде, кто не очень хорошо справляется с организацией собственных дел
https://youtu.be/t_jZMmXRjGM

В противопоставлении document-centric и software-defined подходов я намеренно опустил один важный момент.

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

Мы можем каждую из активностей в этом процесе описать в виде подробного документа, дать с ним ознакомиться сотрудникам, проводить регулярное обучение и адаптировать в виде инструкций.
Либо можно для каждой из активностей написать портянку YAML, написать тесты и CI/CD для раскатки этого YAML, перевести на разработанные скрипты автоматизации все процессы разработки.
Для каждой активности назначить ответственного сотрудника, который будет регулярно обновлять и дорабатывать регламенты (в случае документоцентричного подхода) или дописывать новый YAML по запросу разработчиков (в случае кодоцентричного подхода).

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

Вместо методологии DevOps появились devops-инженеры ровно в тот момент когда мы из software-defined процессов убрали ориентацию на результат и заменили ее автоматизацией отдельных шагов.

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

Предположим, некий "devops-инженер" пишет разнообразную автоматизацию пайплайна SDLC для своей команды разработки.
- Его видимая работа состоит в написании различных автоматизаций на YAML. Эти задачи можно положить в таск-трекер и проконтролировать их выполнение.
- Следующий слой работы состоит в интеграции отдельных шагов пайплайна так, чтобы артефакты между ними передавались правильно и без ошибок. Эти задачи в таск трекер положить можно, но только либо в виде самого описания или definition of done задачи по реализации шага пайплайна, либо в виде багов — когда один шаг вроде бы интегрирован с другим, но дает неверные результаты. Причем, технически эту задачу отделить от первого шага вполне реально — я часто советую ребятам сделать два эти шага по отдельности, когда они буксуют над подобной составной задачей
- Слоем глубже находится построение поведения пайплайна, состоящего из нескольких шагов. Например, мы сперва публикуем контейнер в хранилище, дальше этот контейнер сканируем на уязвимости и подписываем ключом, и в конце разрешаем запуск контейнеров на средах только если они подписаны. Эту задачу можно положить в таск-трекер как набор отдельных задач, но для того чтобы реализовалась именно функциональность "разрешить запуск только контейнеров просканированных на уязвимости" нужно эти задачи или объединить в какой-нибудь эпик, или тщательно описать что должно происходить для каждой из задач, или описать весь процесс отдельным документом и прикрепить его к каждой из задач. Создание такого описания и декомпозиция его на тикеты может быть отдельной задачей перед собственно написанием автоматизации на YAML, и задачей окажется довольно немаленькой.
Ну или можно завести одну большую задачу "реализовать проверку подписи контейнеров", подразумевая всю эту цепочку, и отдать выяснять детали самому инженеру. Но тогда как состояние выполнения этой довольно немаленькой задачи, так и собственно способ ее реализации становятся плохо верифицируемыми для стороннего наблюдателя. Иными словами, если мы ставим такие достаточно большие составные задачи (или мини-проекты) мы должны быть уверены в том, что сотрудник умеет их решать, и решает их хорошо.
- Если идти еще глубже, мы приходим к построению принципов и стандартов работы пайплайна самого по себе, и как они будут интегрироваться с рабочим процессом команд разработки. Из этих принципов у нас появляются задачи на реализацию элементов функциональности пайплайна — т.е. задачи предыдущего слоя. Такой вид задач требует как знания предметной области ("как правильно строить пайплайны") с одной стороны, так и совершенно нетехнических компетенций с другой стороны — навыков анализа систем, планирования процессов и декомпозиции решений на элементарные задачи.

Все это хорошо, но какая здесь связь с DevOps?

Дело в том, что ориентация на результат, анализ сложных систем и планирование их реализации — это набор необходимых характеристик любого технического руководителя. Декомпозиция целевого решения на отдельные задачи тоже.
Вся суть "методологии DevOps" состоит в том, чтобы включать в активности по проектированию целевой системы не только функциональные и нефункциональные требования заказчика, но также и части системы связанные с Инфраструктурой и SDLC. Это не столько "методология" или "философия", сколько домен знания наподобие "проектирования интерфейсов" или "построения даталейков".
Скорее всего будучи руководителем, реализацию различных частей системы ты отдашь сотрудникам с соответствующей квалификацией.
В этот момент и возникает потребность в devops-инженерах, которые на деле являются такими же разработчиками как фронтендеры, тестировщики или разработчики на Java.

Друзья из Флант недавно попросили меня поделиться видением того, куда движется DevOps и индустрия, и что с ней станет лет через 10.
После того как они опубликовали свою статью я понял, что хочу немного развернуть свои ответы.

В телеграм такой длинный пост не влезает, прочитать его можно у меня на сайте:
https://timurb.ru/kb/kuda-idet-devops/
https://timurbatyrshin.medium.com/ed8c5fd01b02

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

20 апреля, в субботу через две недели, выступаю на онлайн-конференции «Systems Design» по проектированию ИТ-систем с докладом «Построение модели грейдов через моделирование цепочек добавленной ценности».

Расскажу о том, как построение Value Stream можно использовать не только для построения CI/CD-пайплайнов, но и для быстрого построения модели предметной области любого процесса, и для разворачивание этой модели в набор требований — в данном случае, например, в требования к грейдам в компании.

Кому конференция будет особенно полезна?
— Разработчикам
— Архитекторам
— Системным аналитикам
— ИТ-специалистам, которые интересуются вопросами проектирования

Более подробно про конференцию, воркшопы и доклады Вы можете узнать в отдельном TG-канале и на сайте конференции

Об менеджерское и инженерное рассмотрение процесса разработки [1/2]

Если продолжать обсуждать переход от документо-ориентированных (document-centric) процессов управления к программно-задаваемым (software-defined) (предыдущие посты: раз, два, три), легко упустить одно обстоятельство, которое одновременно наиболее ярко покажет совершившуюся революцию (и возможно окажется, что это революция консервативная).

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

Менеджера в общем мало интересует содержание отдельных работ, его интересует выполнение взятых на себя обязательств исполнителями: чтобы разработчики в срок разработали код фичи и передали его тестировщикам, чтобы тестировщики протестировали фичу и передали его для деплоя на продакшн и т.п. Одна из основных задач менеджера - контроль таких обязательств. Если тот, кому передали результаты некоторой работы подписал акт приемки, менеджеру в целом не важно, работает ли фича на самом деле, закрывает ли она потребности клиента, т.к. обязательства прописанные в контракте выполняются. Ошибка на продакшне это всего лишь повод либо добавить в контракт "гарантийный срок на поставляемый результат" (как обязательство устранять дефекты в течение этого срока), либо открыть отдельный контракт на поддержку. И это все совершенно нормально и правильно, т.к. контракт за выполнением которого он следит - это интерфейс через который взаимодействуют организации. Если контракт плохо организован, начнет сбоить само взаимодействие.

Инженера же, напротив, интересует в первую очередь как именно происходит работа. Не соблюденный технологический процесс не приведет к тому результату, который мы ожидаем, в непротестированном коде почти наверняка будут ошибки. При этом, любая инженерная деятельность по своей сути весьма неравномерна — разработчик не может сказать "я написал код к фиче, как ее дальше будут тестировать и деплоить, и будет ли фича в принципе работать мне не важно". Почти всегда потребуется то или иное его участие и в других фазах. Ошибка найденная при тестировании или на продакшне возвращается к нему, и ее потребуется исправить. Для получения успешной системы в продакшне важно не только выполнение отдельных работ, но и весь технологический процесс, который поставляет результат в продакшн. В нем в отдельных фазах в принципе может не быть людей, а в других фазах могут участвовать одновременно несколько командных ролей, при этом у этих участников нет явно формализованной ответственности за участие в этой фазе. Если тестировщик нашел багу в написанном коде, разработчик садится с ним рядом и они вместе разбираются в чем там проблема, а не перекидывают тикеты друг другу ("-Я протестировал и нашел ошибку. -А я исправил. -А я снова потестировал и снова нашел"). При этом сбой на ранней стадии сквозного технологического процесса с большой вероятностью приведет к проблемам на его поздних стадиях, и поэтому этот процесс нужно проектировать также как и любой объект инженерной деятельности, и настолько же тщательно контролировать его реализацию: лучше всего описать его кодом чтобы получить гарантию что он всегда будет происходить именно так как проектировался.

Об менеджерское и инженерное рассмотрение процесса разработки [2/2]

Такое неоднородное вовлечение в процесс хорошо показано на "Горбатой диаграмме" из RUP (см выше).
Слева на право происходят фазы процесса разработки (можно провести параллель с состояниями тикета на доске или шагами пайплайна). Сверху вниз показаны роли, которые участвуют в каждой из фаз, и условный уровень их вовлечения в течение времени работы над проектом или фичей.

Итак, если рассмотреть особенности этих двух ролевые позиций - менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол "devops-инженер должен наладить взаимодействие между разными командами"  —  если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так, см обсуждение: Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса - подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак "равно" между ITIL и DevOps. ITIL - дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.

There is no “i” in IaC