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

Закреплю ссылку на чат

https://news.1rj.ru/str/rect_arrow_chat

Презентация с моего выступления на archdays 2022

Как вписать архитектора в команду

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

Мне показался интересным опыт коллег из Райфа, которые "перевернули" процесс.

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

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

Кажется что должно работать следующее решение:
1. Архитектор оценивая риски проекта описывает проблему (enablers) в форме US
2. Разработчики разгребая беклог с US от разных источников могут делегировать сложные и непонятные задачи архитектору

#АрхитектурныйПроцесс

Team topologies одним листом

System Design Interview

У меня периодически спрашивают, есть ли книжка, в которой процесс проектирования ИС рассмотрен поэтапно.
Мне кажется, что есть - https://www.amazon.com/System-Design-Interview-insiders-Second/dp/B08CMF2CQF

#bookshelf

Верификация архитектурных решений

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

Попытаюсь систематизировать:
1. Архитектурное решение противоречит требованиям
Так как архитектура формируется на базе нефункциональных требований, то и противоречия стоит искать в этой среде.
a. Проверяем на проде (или стайдже), по метрикам.
В частности, так работает эволюционный подход. Попробовали - переделали
b. Строим прототип.
c. Моделируем.
Математические модели производительности или дерево отказов – могут сэкономить много средств.
В конце концов, просто проигрывая различные сценарии, можно получить массу полезной информации.
2. Архитектурное решение противоречит техническим возможностям.
Архитектура не может быть реализована
a. Передаем разработчикам и ждем обратной связи.
Возможно разработчики сразу укажут на проблемы, возможно в процессе реализации.
b. Ревью у эксперта.
c. Строим прототип.
3. Архитектурное решение противоречит различным ограничениям (юридическим, безопасности, стандартам и др.)
a. Ревью у эксперта.
4. Архитектурное решение противоречит реальным хотелкам бизнеса
a. выявляется на этапе валидации. Вне скоупа рассмотрения.

В каких случаях полезны различные варианты ревью?
Конечно же все зависит от экспертизы участников, но можно прикинуть основные варианты.
1. Ревью в процессе парного проектирования.
В основном – совместное моделирование. Прикрываем пункт 1.
2. Ревью у разработчиков.
В основном – снимаем технические ограничения. Прикрываем пункт 2.
3. Ревью у эксперта.
Прикрываем пункты 2-3
4. Обсуждение на Арх. коме.
В основном – снимаем ограничения по стандартам и т. п.
Частично прикрываем пункт 3

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

#ВерификацияАрхитектуры

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

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

В моём понимании, архитектор, останавливающийся на этапе проектирования – недо-архитектор. Обитатель башни из слоновой кости.
Ответственность за судьбу проекта требует внедрения (проталкивания) архитектурных решений.
И тут только два пути: либо реализовывать свой проект самому, либо управлять его реализацией.
Так что, хороший архитектор занимается управлением, в самом что ни на есть «кибернетическом» смысле слова.
#управление

Власть архитектора

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

Если вспомнить известную в узких кругах управленцев байку о морковке, управленец должен иметь контроль над морковкой.

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

Вопрос в тему, а какой властью обладает архитектор?

#власть

Власть архитектора 2

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

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

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

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

Коллективный архитектор

Тенденция заменить архитектора "коллективом авторов"
вызывает у меня некоторую настороженность.

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

4D Архитектура

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

Во-первых, это позволяет втискивать в описание планы миграции.

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

Как-то так

https://medium.com/olzzio/the-markdown-adr-madr-template-explained-and-distilled-b67603ec95bb

Заметка по MADR (Мой любимый формат ADR))

Снова о CAP теореме

В тренде переосмысление CAP теоремы. В пору говорить о двух теоремах:
- CAP - как то задумывали математики
- cap - как это воспринимают продаваны и комьюнити.

О чем таки исходная CAP ?

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

После чего предлагается подход BASE (vs ACID) с итоговой согласованностью.

Правда в том ,что в итоге согласованности (в смысле CAP) не будет все равно.

CAP говорит об линеаризуемой согласованности и только о ней.

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

Если ли выход ?
Да конечно - строгая итоговая согласованность.

#CAPТеорема

Смысл архитектора

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

Отчасти так. Особенно в плане неосознаваемых потребностей бизнеса.

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

А задачи и грамотный разработчик реализовать может.

Дерево принятия решений по согласованности. Задача

Загорелся идеей нарисовать дерево принятия решений по согласованности (консистентности)

В моем понимании критериями принятия решения должны быть допустимые феномены/артефакты рассогласования по стандарту 95 года (https://arxiv.org/ftp/cs/papers/0701/0701157.pdf) и приемлемые уровни доступности (полная, постоянная, частичная).

Однако в процессе осознал, что в такой постановке задачу на достижение согласованности ни разу не получал.

Хотелось бы провести опрос (ниже)

#CAPТеорема

Выбор БД

Зачастую при выборе БД используется подход Technology First.
Причины:
1. Нас зацепила реклама и порожденный ею хайп
2. Мы хотим оставаться в тренде (разработка ведомая резюме)
3. Мы используем "проверенный" продукт. И в случае чего можем списать неверный выбор на общую тенденцию.
Ну и самое главное - мы зачастую не умеем выбирать, ориентируясь на задачи и цели.

Например:
Заказчик хочет сохранять метаданные в гео-распределенной системе с поддержкой протокола синхронизации RAFT или аналогичного (так в ТЗ ))
Варианты решения:
- У нас есть проверенный годами инструмент zookeeper. Зачем еще что-то придумывать ?
- Я очень хочу попробовать Cassandra. Возьмем ее
- В распределении хороша MongoDB. Да, все сидят на монге!

А как иначе ?

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

И если уж начинать с изоляции, то нужно правильно сформулировать задачу.

Судя по опросу, да и по опыту, писать задачу от феноменов бессмысленно.

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

Например так:
5. В транзакциях могут быть операции вставки и операции чтения по предикату
Возможны фантомы, Phantom
Решения:
1. Модель акторов (сервис, обрабатывающий транзакции по очереди)
2. Предикативная блокировка
3. MVCC с откатом опасных транзакций нарушаемых вставкой
4. Транзакция от уровня Serializable

И это сразу бы сузило число претендентов на МОЮ БД )

#БД