Fundamentals of Enterprise Architecture (Рубрика #Architecture)

Прочитал на каникулах книгу Tanu McCabe, что была посвящена корпоративной архитектуре и вышла квартал назад, а точнее в сентябре 2024 года. Мое мнение, что корпоративная архитектура - это удел корпораций, что сначала запускали devops трансформации, потом digital трансформации, а теперь все гонятся за AI. В общем, если у вас не технологическая компания, то enterprise architecture вам может и пригодится. В этой книге Tanu McCabe делает подход к снаряду, чтобы придать корпоративной архитектуре современный вид и теоретически у нее получается неплохо, но неясно как это стоит осуществлять на практике, хотя каждая глава сопровождается практически анекдотами, где приводятся примеры плохой реализации корпоративной архитектуры и хорошие варианты, что соответствуют современным тенденциям. И у нее достаточно неплохо это получается

Если говорить про основные мысли книги, то они изложены в первой главе, где затрагиваются следующие моменты

1) Зачем нужна корпоративная архитектура? И автор отвечает, что она нужна для
- Избегания изоляции отдельных частей организации (avoiding silos)
- Избегания хаоса - здесь идет речь про борьбу с complexity через стандарты
- Избегания технического долга, который мешает инновациям и бизнес гибкости
Все три вещи выше являются признаками неэффективной корпоративной архитектуры, а вот эффективная помогает сформулировать технологическую стратегию на каждом уровне корпорации и помогает поставлять нужные решения

2) Автор описывает vision, mission, что должны быть у корп архитектуры и приводит generic примеры

The vision: Define technology strategy that transcends organizational differences to connect different aims into common business goals.
The mission: Enable great architecture decisions to deliver great solutions as one team.

Читатели могут взять эти или придумать для себя сами.

3) Автор описывает функции корпоративной архитектуры, куда входят strategy, oversight, enablement, пересечение которых обеспечивает крутые архитектурные решения.
- Стратегия помогает в достижении бизнес-целей организации - для этого важно про них знать
- Enablement мне напоминает по описанию то, как компании создают платформы для поддержки работы своих компаний
- Oversight включает в себя governance, risk, compliance

4) Автор рассказывает про роли архитекторов: enterprise, solution, software. Тут примерно то же самое, что я рассказывал 4 года назад в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения". Правда, у нас не было корпоративных архитекторов, а их роль лежит на технических директорах как мне кажется:) Эти ребята принимают решения разных volume и scope.

5) В принятии архитектурных решений помогают специализированные функции, что включают security, network, cloud, SRE, data, compliance и так далее. В общем, это похоже на привлечение центров экспертиз для принятия важных решений.

6) Бывают разные организационные модели: централизованная, федеративная и гибридная
- В централизованной модели роль корпоративной архитектуры централизована и находится на уровне других топ-левел орг юнитов.
- В федеративной модели роли распределена по отдельным доменам
- В гибридной есть небольшая центральная часть, а основная часть федеративна

7) Автор описывает типичные архитектурные deliverables, что включают
- Architecture decision deliverable - подробнее можно почитать здесь
- Architecture pattern deliverable - это паттерн для решения типичной проблемы внутри организации, желательно с объяснением логики и примерами кода
- Capability target architecture deliverable - это целевое описание группы возможностей, которое можно назвать архитектурным доменом. Про это интересно рассказать в отдельном посте
- Application target architecture deliverable - это целевое описание архитектуры приложения

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

#Architecture #Management #Leadership #Software

DevOps Metrics. Your biggest mistake might be collecting the wrong data (Рубрика #Management)

Ради интереса я решил прочитать whitepaper шестилетней давности, в котором Nicole Forsgren и Mik Kersten рассказывали о devops метриках. Интересно, что статья начинается с цитат великих

“Software is eating the world.” —Marc Andreessen
“You can't manage what you don't measure.” —Peter Drucker

А дальше начичнается погружение в эру digital и devops трансформаций и продажа разнообразным CIO рассказов о том, что организации зачастую не достигают целей IT из-за проблем со скоростью поставки программного обеспечения. И для того, чтобы улучшить эти процессы авторы предлагают поработать над созданием метрик, которые позволят обеспечить прозрачность и управляемость в этой области. Для этого они предлагают комбинировать 2 типа данных

1) System-based metrics
Это метрики, которые строятся на основе данных из реальных систем. Например, данные о сборках, автотестах, релизах, работе в IDE и так далее. При рассмотрении этих данных требуется учесть аспекты
- Completeness - достаточно ли полны данные, собранные из определенной системы для обеспечения той наглядности, метрик и отчетов, которые являются целью инициативы?
- Comprehensiveness - достаточно ли данных собрано во всех системах для учета сквозной метрики, например, time-to-market?
- Correctness - достаточно ли скоррелированы данные, чтобы быть правильными? Условно надо уметь матчить совпадающие данные из разных систем
У этих метрик есть крутые преимущества
- Precision - данные в системах создаются с большой точностью
- Continuous visibility - данные из систем доступны в реальном времени, можно работать на потоке данных или анализировать их пост-фактум
- Granularity - мы можем смотреть на данные из разных подсистем или компонент или наоборот подняться на уровень системы
- Scalability - когда система сбора данных имплементирована, то ее можно растянуть на все продукты/проекты
Но есть и сложности
- Gaining a holistic view - во-первых сложно собрать данные со всех систем (нужен тулинг), а также из-за того, что у нас социо-технические системы, то нужна информация из глаз разработчиков о том, как работают инженерные процессы
- Capturing drifts in the system - при изменениях в системах данные из них могут не обновляться, что дает неактуальную картину

2) Survey-based metrics
Это метрики на основе проведения опросов о том, как работают процессы, системы или сами люди чувствуют себя:) У таких данных есть следующие важные аспекты
- Cohesiveness - данные, полученные в ходе опросов, особенно хороши для предоставления полного и целостного представления о системах.
- Correctness - разработка и измерение опросов является хорошо изученной дисциплиной, которую можно использовать для предоставления качественных данных и понимания систем и культуры.

У этих метрик есть крутые преимущества
- Accuracy при правильном сборе данных
- A holistic view of the system - ответы, которые предоставляют респонденты, отражают их общее восприятие ситуации
- Triangulation with system data - можно сочетать с системными данными
- Capturing behavior outside of the system
- Cultural or perceptual measures related to the system
Но список недостатков тоже широк: precision данных не очень велик, получать данные постоянно невозможно (никто не будет заполнять опросы слишком часто), объем собранных данных (мало кто готов заполнять сложные опросы даже редко). А также если данные опросов используются для оценок, то ответы в опросах могут быть смещены в сторону ожиданий топ-менеджмента.

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

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

The Culture Map (Карта культурных различий) (Рубрика #Management)

Прочитал на каникулах этот бестселлер десятилетней давности от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя
1. Communication (коммуникация): low-context vs. high-context
2. Evaluation (оценивание): direct vs. indirect negative feedback
3. Persuading (убеждениe): principles-first vs. applications-first
4. Leading (лидерство): egalitarian vs. hierarchical
5. Decision-making (принятие решений): consensual vs. top-down
6. Trust (доверие): task-based vs. relationship-based
7. Disagreement (несогласие): confrontational vs. avoidance
8. Scheduling (планирование времени): structured vs. flexible24

Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось
1. Communication (коммуникация)
- Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00"
- Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность.
2. Evaluation (оценивание
- Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки".
- Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы".
3. Persuading (убеждениe)
- От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы.
- От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные.
4. Leading (лидерство)
- Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении.
- Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству.
5. Decision-making (принятие решений)
Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования.
Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов.
6. Trust (доверие)
На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков.
На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы.
7. Disagreement (несогласие):
Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч.
Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации.
8. Scheduling (планирование времени)
Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками.
Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств.

В итоге, книга через модель и примеры помогает читателям взглянуть на другие культуры непредвзято и оценить какие недоразумения возникают из-за культурных различий, а не некомпетентности. Это позволяет преодолеть культурные границы и может помочь менеджеру мультикультурной команды
- Определить потенциальные области конфликтов между культурами
- Адаптировать стиль управления под конкретную культуру/культуры
- Улучшить коммуникацию в международных командах

P.S.
Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid.

#Management #Leadership #Culture #PopularScience

What Do Developers Want From AI? (Рубрика #DevEx)

Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи

1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Новогодний отпуск

Мой отпуск уже заканчивается, завтра на  работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о  прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers

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

P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)

Grokking Continuous Delivery (Грокаем continuous delivery) (Рубрика #DevEx)

Одной из книг, что я прочел на новогодних каникулах стала книга Кристи Уилсон из Google про современные подходы к continuous delivery. Я достаточно осторожно отношусь к книгам из серии Grokking, но тут меня подкупило, что вступительное слово написало целых два крутых инженера, что точно умеют в инженерию
- Джез Хамбл, что был соавтором книг "Continuous Delivery", "DevOps Handbook", "Accelerate" (я уже рассказывал про первую и третью книги из этого списка)
- Эрик Брюэр, что сформулировал CAP теорему (я уже рассказывал об этом), а потом участвовал в разработке Google Spanner, а сейчас VP Infrastructure & Google Fellow
Оба этих уважаемых джентельмена очень хорошо отзывались о книге во вступительном слове, поэтому я был в предвкушении интересного чтения ... и так и получилось. Но интересность была обусловлена не rocket science подходами, а скорее тем, как Кристи буквально с основ объяснила как выглядит разработка софта и зачем нужен continuous integrating, continuous delivery и чем он отличается от continuous deployment.

По-факту, в книге 4 части, 13 глав и 2 приложения, которые чем-то напоминают мне комиксы - во многих главах разбираются почти реальные проблемы выдуманных компаний навроде "Cat Picture", "Super Game Console", "Ice Cream for All", "CoinExCompare" и так далее. Это позволяет автору продемонстировать эволюционное развитие подходов к инженерным процессам, а не сразу показывать идеальную картинку. Кстати, по оглавлению уже можно понять как выстроена логика повествования

Part 1: Introducing continuous delivery
Chapter 1: Welcome to Grokking Continuous Delivery
Chapter 2: A basic pipeline
Part 2: Keeping software in a deliverable state
Chapter 3: Version control is the only way to roll
Chapter 4: Use linting effectively
Chapter 5: Dealing with noisy tests
Chapter 6: Speeding up slow test suites
Chapter 7: Give the right signals at the right times
Part 3: Making delivery easy
Chapter 8: Easy delivery starts with version control
Chapter 9: Building securely and reliably
Chapter 10: Deploying confidently
Part 4: CD design
Chapter 11: Starter packs: From zero to CD
Chapter 12: Scripts are code, too
Chapter 13: Pipeline design

Из важного стоит отметить, что Кристи
1) Старается не привязываться к инструментам для CI/CD (для этого есть первое приложение, где рассматриваются их возможности)
2) Дает инструкции по настройке пайплайнов как для green-field, так и для brown-field проектов
3) Акцентирует внимание на лучших практиках: VCS как источник истины, безопасное развертывание с использованием автоматизации, использование шагов пайплайна для получения правильных сигналов о готовности софта для развертывания, отслеживание качества процесса поставки при помощи DORA метрик (подробнее про них в книге Accelerate, о которой я рассказывал в трех частях 1, 2 и 3)

В общем, несмотря на мое глубокое погружение в тему книги, она даже мне принесла новые знания, а также систематизировала понимание. Я бы с большим удовольствием прочел ее в самом начале карьеры, чтобы сократить количество граблей, которые приходилось проходить самому:) Так что я очень ее рекомендую для тех, кто сейчас начинает свой путь в IT - лучше познакомиться с теорией о том, как должны выглядеть инженерные процессы из книги, чем пытаться самому прийти к ним на практике. Это точно сократить путь к становлению лучшим инженером.

P.S.
Книга на русском вышла в издательстве "Питер" и как по мне она переведена достаточно неплохо:)

#Devops #Management #Leadership #Processes #SRE #Software #Devops #Architecture #SoftwareDevelopment