О пользе эволюционной архитектуры

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

Нил Форд описывает различные способы выявления риска:
1. Прототипирование
2. Моделирование (в том числе математическое)
3. Эволюционный подход (пустим в прод. и посмотрим, что получилось)

Кроме этого я бы добавил очевидное:
1. Выявление рисков на основании опыта (по аналогии с предыдущими проектами)
2. Выявление рисков на основании чужого опыта (изучая архитектурные концепты, в частности паттерны)

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

В плане скорости и стоимости принятия решения ранжировал бы так
1. Опыт
2. Паттерн
3. Модель
4. Прототип
5. Проба в проде

Однако, в плане точности предсказания ранжировать достаточно трудно.
Опыт (свой и чужой) может обмануть – у каждого проекта своя специфика.
Математика – слишком абстрактна. Можно упустить значимое.
Прототип тоже не засветит всех грядущих проблем.

Единственно надежный вариант – попробовать.
Дорого и сердито.

Ещё одна классификация архитекторов

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

1. Специалист (опыт)
2. Теоретик (паттерны)
3. Инженер (модель)
4. Кодер (прототип)
5. Экспериментатор (проба в проде)

Надо бы протестировать эту модель на собеседованиях )

В продолжении темы.

Много более осмысленный текст:

Заменят ли боты технических писателей ?
PERPLEXITY
View Concise
It is unlikely that bots will completely replace technical writers in the near future
[2]
[3]
[5]
. While AI and automation tools can be used to assist with certain aspects of writing, such as generating content quickly and accurately
[1]
, they are not yet sophisticated enough to consider all the humanly factors important for good user manuals
[2]
. Additionally, AI tools are not yet able to communicate effectively with subject matter experts or other teams
[2]
.Therefore, while AI and automation tools may change the writing profession in a number of ways, such as making some roles redundant and creating new career opportunities for writers who use them
[3]
, it is unlikely that they will completely replace technical writers in the near future
[2]
[3]
[5]

Джуниор архитектор

Обобщая сказанное выше:
1. Архитектор находит и оценивает риски/проблемы, возникающие при реализации решений.
2. Архитектор находит проблемы не только по условиям задачи (дано), но и во всём контексте задачи.

Существует только три способа обнаружения риска:
1. Быстрый, на основе опыта (специалист)
2. Дорогой, через "попробовать" (экспериментатор, эволюционная архитектура)
3. "Средний путь", через делегирование проблемы (вынос обсуждения на совещания)

Может ли быть полезен начинающий архитектор без опыта, для которого первый вариант не приемлем?

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

В плане оценки архитектурных решений популярны два метода:
1. Классика ATAM от SEI (со многими альтернативными вариантами)
2. Эволюционная архитектура от Нила Форда и к.

В первом случае нас призывают собрать совещание и пригласить туда всех стейкхолдеров.
Во втором написать сценарии верификации архитектуры (фитнес функции).

У меня есть веские основания сомневаться в полезности фитнес функций при выявлении рисков в контексте задачи.

То есть вывод простой:
Джуниор архитектор возможен, но только в режиме непрерывных совещаний по оценке рисков.

#ArchReview

О шарлатанах

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

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

Если у бизнеса нет денег на опытного архитектора, то почему бы не пойти итерационно (оно же гибко).

Если деньги есть, то не факт, что нанятый архитектор не окажется шарлатаном.
Увы.

То есть эволюционная архитектура выглядит дорогим, но предсказуемым процессом.

Поиск специалиста с опытом - рулетка.

И наконец https://chat.openai.com/
(Я однозначно буду это использовать) )


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

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

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

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

Паттерны и Сюхари

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

Но я все-таки не буду столь категоричен.
Всему своё место. Есть место и архитектурным паттернам.

Если вспомнить японскую модель обучения боевым искусствам Сюхари
(https://ru.wikipedia.org/wiki/%D0%A1%D1%8E%D1%85%D0%B0%D1%80%D0%B8
https://martinfowler.com/bliki/ShuHaRi.html),
то освоение любого материала можно разбить на три ступени:
- Сю (守) — первая ступень, означающая, что надо заучивать всё точно так, как показывает учитель.
- Ха (破) — вторая ступень, на которой ученик обдумывает свои действия, изменяет правила, пробует их нарушать
- Ри (離) — третья ступень, согласно которой нужно освободиться от правил

На ступени Сю паттерн необходим, как образец для копирования.
На ступени Ха паттерн используется для изучения ограничений.
И только на ступени Ри паттерн теряет смысл.

Кроме того, имена паттернов крайне удобны при коммуникации.
Сравните:
- Сервис группировки сообщений
- Message Router
Какое из этих наименований расскажет Вам больше о цели и реализации компоненты ?

#АрхПаттерны

Использование паттернов в общении

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

Однако не указано одно важное ограничение - наличие общего тезауруса.

За конкретным термином участники взаимодействия должны видеть одно и тоже.

В наше время это преимущество паттернов почти утрачено.

Паттерны не в моде. Многие их не знают или знают понаслышке.

Попросил я как-то написать брокера...

Таким образом , увы, в начале пишешь текст с указанием паттернов. Потом отдельно каждый объясняешь.

Архитектор и корпоративная культура

Когда-то на курсах по управлению нам рассказывали, что существует три типа корпоративной культуры:
1. Административная (она же бюрократическая), в которой решения обусловлены требованиями начальника.
Девиз: «Я начальник – ты дурак».
Главный актор – Начальник.
2. Техническая, в которой проводятся решения технических специалистов.
Девиз: «Руководить — это значит не мешать хорошим людям работать» (академик Петр Капица).
Главный актор – инженер.
3. Сервисная, т.е. клиенто-ориентированная.
Девиз: «Клиент всегда прав»
Главный актор – клиент маркетолог, так как именно он формирует желания клиента.

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

В корпорации первого типа архитектор не нужен. В свое время китайские правители заменили строптивых технократов на лояльных евнухов и были правы.
Основной вопрос, решаемый начальником – вопрос власти (удержаться или расширить). Соответственно и все решения должны приниматься в этом ключе.
Решение должно удовлетворять вышестоящего сюзерена (скорость, бюджет, киллер фича), а все неприятности должны быть заметены под ковер.
Задача начальника – уйти на повышение до того момента, когда все взорвётся, или использовать схему «три письма».

В технической культуре процветает перфекционизм. Строим на века. Взвешиваем и просчитываем по семь раз. Архитектор – бог. Только здесь у архитектора есть власть, и только здесь он может отвечать за реализацию своих решений. Схема хорошо работает в случае неиссякаемого денежного потока. Например, какой-нибудь Боинг или атомный проект.

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

Пример работы архитектора в каждом случае приведу в следующем посте.

А пока небольшое резюме:
Перед тем, как определить обязанности архитектора и сформировать процесс, неплохо бы определить с каким типом культуры мы имеем дело.

#КорпоративнаяКультура

Архитектор и корпоративная культура
Практический кейс (по посту выше 🖕)

Задача:
Необходимо обеспечить хранение правил авторизации (ABAC) в гео-распределенной системе.

1. Административная культура
Решение должно быть быстрым и дешёвым. Но при этом, в случае провала, должна быть возможность «делегировать» проблему на кого-нибудь другого.
Правильный ответ: Postgres
Правда, в этом случае у нас на роли архитектора лояльный разработчик, поэтому выбор не оптимальный – MongoDB .)

2. Техническая культура
Нужна казуальная согласованность. Нужно учесть требования по надежности, 0downtime, производительность.
MongoDB не дает нужной консистентности.
Не попробовать ли CoackroachDB?
По ходу внедрения освоим и воспитаем специалистов по поддержке.

3. Сервисный подход
Служба эксплуатации ни за что не осилит поддержку CoackroachDB. Накоплен опыт по использованию Postgres.
Postgres + Patroni.
Достойный компромисс при отсутствии вариантов.

#КорпоративнаяКультура

Мне подсказывают, что есть еще одна культура - мобилизационная.
Здесь правят военные, подчиняясь понятию чести и слову Надо.

Возможно так. Сам не сталкивался.

Вернее слышал как проходит приемка на объектах ВПК (работал там консультантом).
Предполагаю, что есть и другие "правильные" военные.

Текущая и целевая архитектуры

Ранее я активно упоминал два вида архитектур: текущею и целевую.
Опишу их подробнее.

1. Текущая (As Is). Фиксирует результат. Может быть снята с уже реализованной системы.
Отнюдь не только структура. Сюда относятся также решения и резоны, по которым эта структура формировалась.
В следствии этого автоматическое формирование описания As Is архитектуры весьма проблематично. Требуется пообщаться с автором или разработчиком, посвященным в детали.
Архитектуру As Is обоснования по которой утрачены часто называют «Унаследованной» (Legacy)
Перед тем как работать с унаследованной системой её необходимо осмыслить, т.е. попытаться понять причины ее формирования.
Без этого получаем «вялотекущую» архитектуру.

2. Целевая (Target)
Целевая архитектура показывает как должно быть. Мне нравится размазывать целевую архитектуру во времени (подход 4D, https://news.1rj.ru/str/rect_arrow/101), формируя представления на ближайшие этапы реализации и итоговое представление, как недостижимую цель.
Замечу, что в процессе построения решения я использую и другие типы целевых архитектур. Вот они:

2.1. Базовая архитектура
Так как я начинаю формировать архитектурное решение с поиска противоречий, мне нужно определить, чему противоречат новые требования.
Можно попытаться «примерить» новый функционал на текущую архитектуру, но это не всегда удается. В текущей архитектуре может не оказаться подходящих структур.
В этом случае я выбираю простейшее (самое дешевое) решение (например, rpc-http сервис + Postges) и примеряюсь к нему.
Выявленные противоречия (чаще всего по NFR) дают мне первый список архитектурных задач.
Базовое решение обычно сразу же привязывают к текущему/выбранному архитектурному стилю.

2.2. Идеальная архитектура
Получив список задач и требований, я могу построить идеальное решение, то есть решение без учета ограничений.
Как бы выглядела архитектура если бы меня не сдерживали бюджет и технологические ограничения.
Часто на этом этапе я не выбираю готовые продукты (те же БД), а формирую представления продукта, который идеально бы решил поставленную задачу.
Идеальная архитектура дает мне вектор. И я стараюсь не залочить путь к этому решению.

2.3. Собственно целевая архитектура
Опускаясь с неба на землю, я начинаю натягивать на идеальную архитектуру имеющиеся ограничения.
Здесь слишком дорого. Здесь команда выставляет слишком большие сроки. Это технически нереализуемо (пока), а это противоречит имеющимся интерфейсам.

Уродливый результат компромиссов я и выдаю за целевую архитектуру )

#ЦелеваяАрхитектура #ТекущаяАрхитектура

Целевые архитектуры в различных культурах

Продолжу тему.

Рассмотрим, до какого уровня целевой архитектуры доходят в различных корпоративных культурах.

1. Административная культура принимает базовую архитектуру. Нефункциональные требования не выявляются. Производительность, доступность, безопасность поддерживаются только в том случае, если они явно заказаны.
По умолчанию предполагается, что система и так хороша.
Риски не воспринимаются. Архитектор должен не озвучивать проблемы, а решать их, притом в рамках заранее оговоренного бюджета.
Менеджер уверен, что любой инцидент можно решить закрытием тех. долга на уровне разработчиков.
Если же архитектурные проблемы перебивают пользу, формируем новую версию системы.
2. Техническая культура тяготеет к идеальной архитектуре. Принимаются лишь самые существенные ограничения. Например, предельные сроки разработки. Но и их зачастую не соблюдают.
Совершенный продукт может быть бесполезен по соотношению прибыли к затратам. Дорогущий монстр. И хорошо если талантливый архитектор отработал на пользу. Иначе вундерваффе.
3. Сервисный подход - это компромисс. Обычно это решение худо-бедно попадает в требования и в общем случае, хоть и раздражает, но вполне удовлетворяет стейкхолдеров. Технический специалист может признать компромиссное решение безобразным, но работающим.
Главное чтобы всем стейкхолдерам результат не нравился в равной степени )

Резюмируя:
1. Административная культура хорошо справляется с решением типовых задач. Технически сложные системы придется многократно перекраивать.
2. Техническая культура хороша для решения сложных и "нерешаемых" задач. Условия успеха - безграничное финансирование и гениальный проектировщик
3. Сервисный подход - хорошее соотношение цены и качества, при вечно недовольном архитекторе )

Коллеги, кто желает получить бесплатную персональную электронную версию книги Distributed Systems 4th edition (2023)
Это здесь:

https://www.distributed-systems.net/index.php/books/ds4/

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

И снова о CAP

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

1. Чтобы условия "AP" CAP теоремы были, выполнены мало просто разрыва соединения. Надо еще, что бы клиент продолжал долбиться в оторванный сервис.
Вроде ничего не мешает ему переключиться на сервис, оставшийся в рабочем кластере, но нет. Хочется работать с конкретным инстансом. (т. н. полная доступность)
2. Если условия "AP" выполнены, линеаризуемость сообщений нарушается. То есть мы теряем возможность единообразно выстроить последовательность модификаций на всех инстансах (по какому-то условному времени).
Клиенты могут не заметить потери консистентности. (т. н. слабая согласованность, например причинная (casual consistency))
2.а. Например, если клиенты не работают с общими данными, они не заметят никаких проблем
3. Даже если линеаризуемость нарушена, никто не мешает нам восстановить ее позже, после восстановления соединения (т. н. строгая итоговая согласованность, strong eventual consistency). Возьмите все изменения и переупорядочите их. Получите корректный стейт.
Для этого зачастую достаточно знать что создание объекта всегда предшествует модификации, а модификация удалению. Хотя чаще требуются более хитрые алгоритмы.
4. Вопреки распространенному мнению итоговая согласованность (eventual consistency) без дополнительных усилий не восстанавливает линеаризуемость в итоге. Сколько не жди система не придет к консистентному (с т.з. данных) состоянию.
4.а. Итоговую согласованность можно обвешать дополнительными ограничениями, и в некоторых случаях это будет работать, т.е. опять таки клиент ничего не заметит.

Резюмируя:
1. CAP - не приговор. Есть возможность крутиться.
2. Итоговая согласованность - не согласованность в строгом смысле слова, но может таковой казаться конкретному клиенту при дополнительных ограничениях.

#CAPТеорема

Поиск альтернативных решений

Ранее, рассматривая возможность использования ТРИЗ в архитектуре, я решал задачу поиска решения.
Коротко, цепочка такая:
1. Описываем ситуацию (требования)
2. Ищем проблему (противоречия)
3. Находим стандартное решение (подбор концепта)
4. Если не получилось, находим нестандартное решение (изобретение)

Однако поиск подходящего решения это для слабаков.
Архитектор должен уметь находить оптимальное решение.

То есть предполагается, что решая задачу, мы напридумывали несколько альтернативных вариантов, и теперь можем не торопясь 🤭 взвесить их в нашей ADR.

Выборы без альтернативы - очевидный моветон.
Еще раз - не надо хватать и детально прорабатывать первое подходящее решение.
Пусть их будет минимум два.

Но что делать если ваш список паттернов краток, и в нем не нашлось не одной альтернативы?

Здесь может помочь простой трюк. Альтернативу можно "изобрести", перемещая во времени и пространстве основную ответственность (responsibility).

Например, нужно запустить пару клиентов в гео-распределёнке (много-цодовость).
Ограничение - хотелось бы избежать лишних меж-цодовых взаимодействий.
Основная ответственность - маршрутизация запросов.
А дальше играемся с пространством:
1. Поместим маршрутизацию на клиента
2. Поместим маршрутизацию на сервис в ЦОДе
3. Воткнем маршрутизацию где-то между клиентом и ЦОДом

Варианты есть. Отбрасываем отчетливо непригодные. Взвешиваем оставшиеся. Профит.

#АрхитектурныеРешения

Распределенный компонент (Distributed Component)

Постоянно рассматривая различные архитектуры, встречаю компоненты гордо именуемые "Сервис" (или даже "Микросервис")
при этом к сервисам отношение не имеющие.

Напомню, что сервис — это автономная единица развертывания (деплоя). Абсолютное же большинство т. н. «сервисов» развёртываются исключительно вместе с «коллегами».

Анти-паттерн известен и назван "Распределённый монолит".
А как назвать сам компонент? Устоявшегося термина нет.

Есть предпочтения?

Расчет эффективности кэша
Бот против человека.

На одном из каналов обсуждалась эффективность кэширования.
Кто-то предложил проконсультироваться у Chat GPT.

Недолго размышляя, я дал боту такую задачку:

Пусть мощность открытой системы (Throughput) -100 tps.
Пропускная способность кэша (Cache throughput) -100 000 tps.
Процент успешных запросов (Hit rate) - 90%.

Каково будет ускорение по пропускной способности при внедрении кэша ?

Ответ от GPT:

Если пропускная способность системы до кэширования была 100 tps и если с добавлением кэша Hit rate = 90% и Cache efficiency = 1000, то после добавления кэша мы можем ожидать следующее:

- 90% из 100 запросов будут удовлетворены из кэша, т.е. кэш будет обслуживать 90 запросов в секунду
- Оставшиеся 10% запросов будут обслуживаться основной системой, которая обеспечивала пропускную способность в 100 tps до внедрения кэша
- Таким образом, общая пропускная способность системы после внедрения кэша должна быть равна суммарной пропускной способности кэша и основной системы:
- 90% от 100 tps = 90 tps, обслуживаемых кэшем
- 10% от 100 tps = 10 tps, обслуживаемых основной системой
- Итого: 90 tps + 10 tps = 100 tps

Таким образом, пропускная способность системы после внедрения кэша останется примерно равной её пропускной способности до внедрения кэша (с учетом погрешностей и ограничений системы).

Решение от программиста незнакомого с программной инженерией:
X = 100.000 * 0.9 + 100 * 0.1 = 90 010 tps
Ускоряемся в 900 раз!

Резюме:
Оба решения абсолютно не верны.
Но все же, говорить, что ChatGPT сравним с начинающим архитектором-ошибочно.

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

Архитектор и владелец продукта (product owner)

У многих коллег складывается мнение, что архитектор и владелец продукта (в agile) - антагонисты.

PO топит за фичи, архитектор за качества, и оба рвут на себя бэклог.

ИМХО здесь и да и нет, или классическое it depends )

Конкретно, все зависит от того, кто берет на себя риски по проекту.

До agile этим занимались менеджеры проекта (PM).

Если владелец риска выделен, то есть на проекте есть PM, то между архитектором и владельцем идет состязание за бэклог. Менеджер занимает сторону арбитра.

После гибких трансформаций в некоторых проектах менеджеров поуберали.
Риски на владельце.
Битва за бэклог происходит в одной голове.

Архитектору остается аккуратно перенести в эту голову все ощущаемые риски, желательно живо описав возможные последствия.
Это в общих интересах.

Сотрудничество )