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

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

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

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

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

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, то между архитектором и владельцем идет состязание за бэклог. Менеджер занимает сторону арбитра.

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

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

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

Архитектор и тимлид

Еще одна пара соперников - архитектор и тимлид.

Тимлид отвечает за сроки. Ему важно вовремя выполнить все задачи итерации.
Архитектор активно мешает. Архитектору хочется чтобы было красиво и качественно.

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

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

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

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

Движение задач в обе стороны.
Если одна из этих труб забивается или вообще не предусмотрена по процессу - быть потопу )

Чего я не нашёл в ТРИЗ

ТРИЗ очень интересная теория. На практике активно применяю алгоритм АРИЗ, и честно говоря, доволен результатом.

Суть алгоритма можно выразить простой последовательностью (см. АРИЗ-77):
АП → ТП → ИКР → ФП → Р
где
- АП - административное противоречие
чего хочет стейкхолдер: требование, user story
- ТП - техническое противоречие
что мешает получить желаемое: технические ограничения, другие требования, принципы
- ИКР - идеальный конечный результат
как можно было бы решить проблему не имея ограничений, например обладая неограниченными ресурсами.
- ФП - физическое противоречие
какой элемент системы является причиной противоречия, например должен выполнять несовместимые функции
- Р - решение
некоторые, считают, что доведя задачу до осознания физических противоречий решение приходит само )

Более подробно расписывал этот процесс на ArchDays
И все казалось бы понятно, но ...

Где тут архитектурные задачи?!

Вместо административного противоречия
("я как ... хочу ... для того чтобы ...")
имеем риск
("при условии ... может случиться ... что приведёт к .... ")

Архитектор именно тот, кто выявляет риски и драйвит задачи по их смягчению.

Возможно ли административные противоречия обобщить на риски?
То есть к понятному "хочу чтобы всегда" добавить "хочу чтобы никогда"

Задумался 🤔

Долгая жизнь проекта
- Часть 1. Проблема

Все проходит.

На картинке жизненный цикл всего, так называемая S-кривая.

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

Отсюда глобальная цель архитектора - вытянуть S-ку, продлить жизнь продукту.

В чём проблема?

В каждом продукте есть решения, которые не возможно или очень сложно переиграть.
Фактически эти решения представляют собой закрытую (от модификации) систему, которая в силу объективных законов склонна к саморазрушению (2НТ).

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

В архитектуре это выглядит примерно так:
Полгода разрабатывали продукт, вышли в прод. а там нагрузка. Требуется 40 инстансов PostgreSQL в режиме master-master. Переписываем.

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

Хотя есть альтернативное мнение )

Выступление с ArchDays добралось до ютюба )

Изобретение архитектурного решения

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

В докладе рассматриваются популярные методы принятия архитектурных решений с привязкой к теории решения изобретательских задач (ТРИЗ).

Пытаемся вместе ответить на вопросы:
— Правильно ли мы ставим архитектурные задачи?
— Достаточно ли знания паттернов и архитектурных тактик для решения сложных задач?
— Каковы ограничения выбора решения из множества вариантов?
— Является ли выбор варианта единственным доступным методом проектирования?
— Существует ли алгоритм, позволяющий выйти на оптимальное решение?

Смотреть: https://youtu.be/tmoOTqPgbFM

Долгая жизнь проекта
- Часть 2. Панацея
Первая часть - https://news.1rj.ru/str/rect_arrow/148

Как можно продлить жизнь проекта?
Очевидное решение - сократить число неподдающихся пересмотру решений (до нуля).

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

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

Архитектура как набор неизменяемых решений больше не нужна!

Долгая жизнь проекта
- Часть 3. Отрезвление

Озвученная в предыдущем посте идея - это основная идея так называемой эволюционной архитектуры от Нила Форда и к.

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

Но точно ли так?

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

Разбиение на сервисы становится тем решением, которое сложно, или невозможно изменить.

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

Увы, MSA не панацея.
Вечная жизнь проекту не грозит (

Все проходит.

Активаторы (Enablers)

Как вводить архитектурные задачи в бэклог?

Популярный фреймворк (каркас) SAFe предлагает особый вид задач, называемых Enablers (Активаторы).
Точнее, Architectural enablers - инструменты архитектуры.

По описанию Enabler - это активность, позволяющая реализовать определённую функцию, поддерживающую бизнес-функции.

Все бы хорошо, но, обосновывая архитектурные задачи, я часто иду от рисков.

Если я скажу, что эта активность добавит нам доступности (99.99) под функцию получения списков, то буду звучать неубедительно.

Если я скажу, что если мы НЕ выполним эту активность, то не выполним SLA и попадём под штрафы - меня как минимум выслушают.

Так что для меня Enablers формулируются как Disablers.

Профессиональная деформация )

Активности SA по формированию архитектуры. Версия 5

Небольшая презентация по использованию законов развития систем ТРИЗ при проектировании архитектуры ПО

В работе "TRIZ for Digital Systems Engineering" Kari Lippert и Robert Cloutier предложили матрицу противоречий для построения программной архитектуры.

Предложены основные качества, но к сожалению не заполнено поле решений.

Выложу здесь, возможно кого-нибудь заинтересует, как заготовка.

Сам я несколько скептически отношусь к использованию матриц противоречий в нашей области.

#ТРИЗ