The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part I (Рубрика #Architect)

Очередное интересное выступление от Simon Brown, создателя C4 Model, на тему моделирования архитектуры. Конкретно в этом выступлении он выступает в качестве человека, который развеивает мифы об использовании C4 Model для этих целей. Начнем с описания того, что Simon говорит о том, что такое C4 Model

- A set of hierarchical abstractions (software systems, containers, components, and code).
- A set of hierarchical diagrams (system context, containers, components, and code).
- Notation independent.
- Tooling independent.

Суть в том, что C4 Model позволяет рассказывать разные истории разным аудиториям - автор показывает это на примере Google Maps, где мы можем от уровня всего Земного шарика спуститься до уровня Google Street View и посмотреть как выглядит наш домик:) Если же переходить к элементам C4 Model, то у нас есть системный контекст, что описывает систему и ее окружение, а контейнеры показывают технологические составляющие и их взаимодействие. А дальше автор перечисляет набор мифов и дальше разбирается с ними

- C4 Model новвая штука на рынке - нет C4 Model существует с 2007 года и обладает общирным тулингом
- С4 Model была создана для замены UML - Нет C4 не создавала как замена UML, она его дополняет структурированным подходом к созданию иерархических абстракций и диаграмм
- C4 Model стала популярна в последние 5 лет? - да, она стала популярнее после пандемии, особенно среди организаций, работающих удаленно.
- Почему Model C4 называется C4, а не C3 - Саймон считает важным, чтобы диаграммы заземлялись на реальность, а именно на компоненты и код (нижние 2 уровня)
- Синий и серый цвет в нотации скучный - Саймон говорит, что вы можете выбрать свой любимый цвет
- C4 модель может быть не ясна, если в ней много текста - Саймон рекомендует использовать много текста, который помогает передать больше информации о системе. А наличие метаданных на диаграммах помогает устранить двусмысленность и правильно интерпретировать диаграммы.
- C4 не создана для фиксации решений по архитектуре прямо на диаграммах - Саймон говорит, что их лучше описывать отдельно в виде ADR (architecture decision records), прикладывая диаграммы из C4 Model для ясности и наглядности
- C4 не содержит deployment схемы - C4 была вдохновлена UML и моделью 4+1 Филиппа Крачтена, в которых deployment схема очень важна. В итоге, вы можете при помощи C4 Model собрать свою deployment диаграмму, где будут контейнеры, системы и инфраструктура.
- Мы не используем C4 Model, так как мы используем DDD вместо этого - это просто бессмысленная штука, которая показывает, что люди, которые так говорят не шарят
- Нейминг container и component не очень хороши - да, но их лучше не переименовывать, так это запутает людей еще больше
- C4 Model is too limiting - автор показывает что 4 уровня абстракции помогают оставаться на определенном уровне абстракции. Если снять ограничение на уровни абстракций, то легко попасть в N-уровней, которые уже сложно различать даже на уровне слов. Саймон показывает пример с неймингом database - это сервер баз данных? конкретная база данных? конкретная схема? В общем, Саймон говорит, что ограниченный набор уровней позволяет внести ясность в обсуждение, а не провалиться во фрактальную история с системами, подсистемами, подпод....системами, в которых сам черт ногу сломит.
- Может добавить дополнительные абстракции? - Саймон объясняет почему следующие термины не очень хороши: подсистемы, bounded contexts, layers. Эти абстракции не добавляют пользы в диаграммах. Часть из этих терминов - это не абстракции, а элементы организации элементов

Продолжение обзора в следующем посте.

P.S.
Я уже рассказывал про другие выступления Саймона на тему моделирования архитектуры
- The lost art of software design by Simon Brown at Devoxx Belgium 2022
- C4 Models as Code • Simon Brown • YOW! 2022
- Continuous Architecture in Practice Eoin Woods & Simon Brown • GOTO 2021

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part II (Рубрика #Architect)

Заканчивая обзор интересного выступления от Simon Brown, я хотел бы рассказать про оставшиеся мифы и советы, которые давал Саймон своим слушателям

- Message-driven architecture и как ее отображать в C4 Model - автор рекомендует отображать не центральный Kafka брокер как контейнер, а отображать отдельные топики как containers или просто указывать их текстом на стрелках, что соединяют контейнеры с разными сервисами
- Общие библиотеки и компоненты - Общие библиотеки и компоненты часто путают, но их следует представлять по-разному. Общие библиотеки лучше изображать как компоненты C4, а не как самостоятельные приложения.
- Микросервисы - микросервисы часто неправильно моделируют как контейнеры с API и схемами баз данных. Микросервисы следует моделировать как программные системы, контейнеры или группировки контейнеров. Важно понимать, что микросервисы могут быть представлены как группа контейнеров или как отдельный контейнер.
- Закон Конвея и микросервисы - по мере роста компании и увеличения количества команд, микросервисы могут стать более сложными. Важно учитывать закон Конвея и создавать микросервисы таким образом, чтобы они были масштабируемыми и интегрируемыми.
- Контекстная диаграмма и разделение сервисов - команда создает веб-приложение, но сервисы передаются отдельным командам. Контекстная диаграмма теперь показывает сервисы как отдельные программные системы. Важно не видеть детали внутренней реализации сервисов, а использовать API.
- Масштабирование и диаграммы - при масштабирования C4 для больших архитектур появляются проблемы. Решение: создание отдельных диаграмм для каждого сервиса. Инструменты, такие как Visio, могут усложнить процесс создания диаграмм, но у C4 Model есть Structurizr
- Модели как код и структура диаграмм - при использование моделей как кода для создания диаграмм мы получаем преимущества: разделение модели на части и предоставление нескольких представлений. Недостатки: упущение общей картины.
- Интерактивные диаграммы и инструменты - интерактивные диаграммы помогают изучать сервисы и компоненты. Можно добавлять метаданные и взаимодействовать с объектами.
- Рекомендации по созданию диаграмм - Саймон предлагает фокусироваться на одной программной системе, избегать показа внешних контейнеров, чтобы избежать зависимости от деталей чужой системы. В качестве примера он показывапет использование общей базы данных как границы между системами.

В конце Саймон напоминает, что C4 Model подходит для создания иерархических абстракций и диаграмм. C4 Model независима от нотаций и инструментов.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Осенняя распродажи в издательстве Питер (Рубрика #Sales)

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

- Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:)
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:)
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте.
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.
- README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга, которые сейчас являются стандартом де-факто. Если книга зайдет, то дам ее почитать 18-летнему сыну, что пошел в этом году на направление геймдизайн (и наконец-то начал читать книги по программированию)
- Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо".
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас уже начал ее читать
- Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее в очень простых примерах, опять же, если книга окажется хорошей, то я смогу ее рекомендовать для начинающих (навроде, моего старшего сына)
- Грокаем функциональное программирование - лет 10 назад еще на Coursera я проходил 5 курсов по ФП, где мы разбирали Scheme, Racket, Scala и другие эзотерические языки программирования. Я так их и не ипользовал в проде, но хочется побботать их опять - вдруг я чуток лучше начну их понимать
- Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники
- Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5
- Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление.
- Чистый Python. Тонкости программирования для профи - я уже больше полугода решаю задачки на Leetcode, используя Python 3. До этого я когда-то использовал Python 2, но и тогда это был мой 3-4 язык из доступного набора по частоте использования. Именно поэтому я решил взять книгу и преисполниться python way по мере ее чтения:)

#Sales

Подборка книг для поста про распродажу в издательстве "Питер"

Code of Leadership #19 - Interview with Evgeny Sokolov about Modern Education

Интервью с Евгением Соколовым, доцентом факультета компьютерных наук НИУ ВШЭ, про то, как выглядит современное образование для software development engineers (Youtube, Yandex Music). Евгений руководит бакалаврской программой «Прикладная математика и информатика», преподаёт машинное обучение. В 2014-2019 годах работал в Яндексе, где успел позаниматься внутренними инструментами для ML, проектами по DS для внешних заказчиков, рекомендательными системами в Дзене.

В этом выпуске мы обсуждаем темы
- Как Евгений пришел в образование из индустрии
- Как ВШЭ выстраивает свое партнерство с компаниями на рыке
- Философия образования
- Архетипы студентов на факультета компьютерных наук (ФКН) ВШЭ
- Продуктовый подход
- Важность фундаментальных знаний 
- Важность понимания дизайна
- Практическое применение знаний
- Взаимодействие с новыми сотрудниками
- Обсуждение дизайна и преподавания
- Типы преподавателей и их привлечение
- Преподаватели из индустрии
- Советы для преподавателей

#Architecture #Software #Management #Leadership #Processes #Education

Обзор 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

Sber Enterprise Architect Framework (SEAF) (Рубрика #Architecture)

Интересное выступление про корпоративный архитектурный фреймворк от Сбера, которая позволяет посмотреть на один их подходов к документированию архитектуры.

Основные тезисы, что я почерпнул для себя
- Этот фреймворк делала несколько лет команда экспертов для для решения проблем управления архитектурой и обеспечения его интеграции в производственный процесс
- Философское наполнение этого фреймворка описано в статье "Архитектор 2.0" на Хабре
- Фреймворк не противопоставляет себя другим фреймворкам, а скорее дополняет их, накапливая и оцифровывая практики - в иллюстрациях приведены DDD, TOGAF, C4 Model, ...
- Фреймворк содержит внутри себя инструменты, пркатики, методологию и артефакты (хорошо, что онтологий нет)
- Целью фреймворка создать цифровую модель предприятия, которая будет иметь неоспоримые характеристики и позволит производить производные.
- Инструментом для автоматизации является DocHub, который я отношу к категории инструментов architecture documentation as a code
- Инструмент позволяет создать рабочее место для архитекторов разных мастей, которые теперь будут рисовать на квадратики и стрелочки для визуализации - теперь они смогут писать это в yaml файлах. Все также как и раньше будет дуализм: 1) то, что происходит в коде и на инфраструктуре и 2) то, что нарисовал архитектор в своих yaml. Зато теперь это можно называть as a Code
- Фреймворк подходит для федеративного управления архитектурой, которая может быть расширяема и адаптирована под нужды каждого домена
- В списке инструментов есть пакетный менеджер, который позволяет скачивать и управлять пакетами с метаданными.
- SEAF стимулирует сообщество к адаптации фреймворка под свои нужды и использовании успешных методологий
- Автор агитирует к переходу от архитектора 1.0 к архитектору 2.0. Архитектор 1.0 - это человек, который визуализирует визуальную схему и модель, в то время как архитектор 2.0 - это человек, который создает архитектуру и постоянно работает над улучшением и заимствованием практик.
- В докладе автор рассказывает про метамодель, которая описана еще и на Github

- Для структурирования метамодели выбран подход разделения ее на слои и вертикали.
- Слои выделяют функциональные области, в то время как вертикали пронизывают их и связывают.
Выделяются слои:
- Бизнес-архитектура;
- Прикладная архитектура;
- Техническая архитектура.

Вертикали:
- Информационная архитектура;
- Управление требованиями.
- Важным принципом метамодели является - адаптивность. Она должна легко подстраиваться под нужды использования. Предусматривать частичное применение, возможность расширения и модификации.
Таким образом, решение о фактическом объеме использования метамодели предоставляется пользователю.

В общем, это хорошая попытка создания фреймворка для реализации подхода architecture documentation as a code.

P.S.
На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать
- Архитектура как код - Роман Пионтик - ArchDays 2022
- Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022
- Материалы к моему докладу "Architecture at T-Bank: how we design our solutions"
- Раз архитектура — «as Code», почему бы её не покрыть тестами?!
- Проводим архитектурное ревью продуктовой фичи
- Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023
- Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

"Founder Mode" и "Notes on Founder Mode" (Рубрика #Management)

Недавно я рассказывал про интересное интервью Брайана Чески, CEO и co-founder Airbnb (1 и 2). В этом интервью Брайан говорил о том, как он поменял схему управления компанией от сильно распределенной обратно в режим основателя компании (founder mode). Брайан подробно объяснял что его побудило сделать такие изменения, а также то, чего они добились со времени изменения.

Недавно, а точнее в сентябре, вышла статья за авторством Paul Graham, сооснователя Y Combinator. В этой статье Пол рассматривал "founder mode" и "manager mode" и отмечал, что до этого момента масштабирование стартапа в Кремниевой Долине неявно предполагало переход от режима основателя к режиму менеджера. Но пример Брайана показывает, что это не обязательно идет компании на пользу. Пол даже вспоминает Стива Джобса и его выезды с ключевыми сотрудниками, которые не относились к самым высоким чинам в корпоративной иерархии. А это нарушает этот иерархичный организационный подход из manager mode

Whatever founder mode consists of, it's pretty clear that it's going to break the principle that the CEO should engage with the company only via his or her direct reports. "Skip-level" meetings will become the norm instead of a practice so unusual that there's a name for it. And once you abandon that constraint there are a huge number of permutations to choose from. For example, Steve Jobs used to run an annual retreat for what he considered the 100 most important people at Apple, and these were not the 100 people highest on the org chart.

Дальше вышла понравившаяся мне статья Anu Atluru, в которой разбирались тезисы Пола Грехема. Вот основные тезисы из нее:
1) Most founders are in “founder mode” and most of them fail anyway
- Most early-stage startup founders are in founder mode by default
- Many founders are first-time founders with zero management experience.
- Founder mode has a dark side risk that can hurt the company and employees
2) Companies don’t fail because founders switch leadership modes. They fail because the mode switch is set up to fail, ill-timed, and rigid
Сценарии, когда classical management приводит к проблемам
- There’s no clear vision and strategy for the company
- The people being managed aren’t the right fit for the job.
- The context is evolving while the “leadership mode” stays rigid.
3) The best CEOs (founder or not) know how to switch between founder mode and management mode — and when they need either one
- Founder mode is akin to the wartime CEO mode. Management mode is more akin to peacetime CEO.
- “Founder mode” and “management mode” can’t be seen as static opposites.
4) A founder’s unique leadership style will put them in their zone of genius and make them happy (mostly)
- Founders need to find their own ideal leadership mode
- The tricky part? It takes practice to figure out.

В итоге, мне кажется, что это очень важные вопросы для крупных компаний, которым важно не застыть во времени и пространстве, а оставаться гибкими и способными реагировать на рыночные изменения и появление конкурентов. Актуально в этом плане посмотреть на Intel и как они из лидера рынка превратились в аутсайдера, которого Qualcomm планирует выкупить и распродать дальше по частям:)

#Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

When to write strategy, and how much? (Рубрика #Management)

Интересная статья про создание стратегии от Will Larson (Lethain) в его крутом блоге. Кстати, Вилл написал уже три книги, каждую из которых я прочитал и каждая по своему мне понравилась:)
Собственно, эта статья представляет главу из еще не написанной книги на тему стратегии. Здесь Вилл размышляет о том, когда пора писать стратегию и насколько она должна быть обширной.
Вот основные мысли, что я извлек для себя
1) Когда писать стратегию?
Организация может быть в трех стратегических состояниях: глобально консистентном (все понимают что и зачем делают), консистентным внутри отдельных команд, совсем разобранном, когда у инженеров мало согласия относительно того, как решать задачи. Собственно, смысл в формализации стратегии есть, если есть неконсистентность. С другой стороны многое зависит от того, куда направлен тренд изменений - если все идет не туда, то есть смысл делать стратегические изменения:) Но даже если все идет не туда, то надо сначала оценить насколько вы понимаете происходящее в организации для написания полезной стратегии. Эффект от стратегии может сведен на нет, если организация слишком часто меняет направление.
2) Насколько много должно быть стратегий?
Это важный вопрос, так как стратегий относительно разных активностей может быть много, но если не ограничивать WIP (work in progress), то по каждой из них результаты будут мизерными. В итоге, тут важна приоритизация и выделение самого важного. Заодно можно часть вещей делать не фундаментально на все времена, а начинать по шагам, которые не пугают участников своим объемом, но приближают вас к цели
3) Масштаб и высота стратегии
Здесь Вилл предлагает поделить стратегии на разрешительные и запретительные. Первые предлагают вариант решения аля (golden path), но не запрещают остальные варианты. В итоге, движение по такому пути выглядит менее напряжным для участников и растягивается во времени. По-факту, тут работа идет через доработку golden paths и adoption инструментов. В запретительных стратегиях есть разрешенный вариант, а все остальное запрещено. Возможны эскалации, но они должны быть единичны. Это более жесткий и быстрый путь. В итоге, разрешительных стратегий может быть запущено одновременно больше, чем если мы будем делать те же самые изменения через запретительные стратегии. Суть в том, что они требуют меньше усилий.
4) Не слишком ли много стратегий вы имплементируете?
Вилл парадоксально отмечает, что хоть и многие инженеры в компаниях считают, что у их компании нет четкой инженерной стратегии, но гораздо больше руководителей терпят неудачу, пытаясь много работать над стратегией, а не мало:) Определить это можно, оценив насколько прошлые стратегические инициативы, повлияли на последующие решения.

P.S.
Книги Вилла в порядке их выхода
- "An Elegant Puzzle" - мой рассказ о книге
- "Staff Engineer" - мой рассказ о книге
- "The Engineering Executive's Primer" - мой рассказ о книге

The Rise of the CAIO (Рубрика #Management)

Недавно мне на глаза попаслась забавная статья про найм CAIO - Chief AI Officers. Я ничего не имею против разнообразных CxO, но по этим новым неймингам можно отслеживать тренды хайпа. Я попробовал вспомнить что из интересного появлялось или набирало популярности за последние 20 лет
- CTO - Chief Technology Officer - когда технологии стали модными
- CKO - Chief knowledge officer - когда стала популярна идея про обучающиеся организации Питера Синге
- CGO - Chief Growth Officer - последние 15 лет, когда все гнались за бешенным ростом (пример с контентными платфомами и соцсетями)
- CDTO - Chief Digital Transformation Officer - когда все внезапно загорелись цифровой трансформацией (даже изначально не digital бизнес)
- CDO - Chief Data Officer - когда данные стали называть новой нефтью
- CAIO - Chief Artificial Intelligent Officer - когда все побежали заниматься искусственным интеллектом
B общем, интересно какой тип C...O нас ждет дальше:)

P.S.
Отдельно отмечу, что часто после появления термина начинается его инфляция - я видел примеры, когда помимо главного CTO и остальных технических руководителей начинали называть CTO примерно так
- CTO больших продуктов (~500 инженеров)
- Дальше CTO отделов (~70 инженеров)
- Дальше CTO команд (~ 10 инженеров)
Финальной точкой может быть сам себе режиссер CTO:)

#AI #Management #Humor #Future