Прямоугольники и стрелочки

Правильно Стоит отметить, что слово "правильно" в архитектуре означает "согласовано с моим пониманием", и ничего больше.

Манифест расширенной модели требований 1. Принцип дополненного ТЗ Контракт в ТЗ (бумажное ТЗ от заказчика) — это лишь надводная часть айсберга. Архитектор не просто пассивно принимает его, а проактивно генерирует внутреннюю (инженерную) модель требований. 2. Принцип легитимности Архитектор имеет полное инженерное и моральное право «докидывать» свои требования, поскольку они не высасываются из пальца, а являются единственным физическим способом обеспечить: - Либо явные, проявленные показатели (FR, NFR). Пример: декомпозиция «1 секунды отклика» на бюджеты задержек микросервисов. - Либо скрытые, непроявленные заинтересованности заказчика. Пример: проектирование модифицируемости ради выживания бизнеса на динамичном рынке. 3. Ловушка формального соответствия Проектное решение обязано целиться исключительно в архитектурную (расширенную) модель требований. Если спроектировать систему только под явный контракт заказчика проект формально попадет в метрики ТЗ, но может провалиться в реальной жизни, потому что разрушит скрытые заинтересованности (система будет невыносимо дорогой в поддержке, не сможет масштабироваться или умрет от блокировок). ___ Предлагаю зафиксировать модель качества как значимый архитектурный документ, развивающийся вместе с архитектурой (вопреки застывшим требованиям) и фиксирующий контролируемые цели разработки. )

☝️☝️☝️ Контекстные допущения и остаточные риски Есть очень "неуютные" кейсы принятия решений под давлением обстоятельств. Например: 1. Менеджер: — Мне сегодня к вечеру нужен технологический стек, иначе мы не согласуем договор. 2. Главный архитектор: — Ты будешь использовать указанную БД, потому что у руководства договорённость с вендором. 3. Саппорт: — Ты, конечно, можешь получать идешки из MDS, но очень не советую. По факту это сырая поделка, которая умеет только падать. В таких случаях рекомендуют вписывать в ADR некоторые "правильные" фразы Например: Контекстные ограничения: Интеграция с существующей master data системой (MDS) исключена контекстными ограничениями. или Остаточные риски (Residual Risks): Решение о выборе БД было принято при не выявленных требованиях к производительности и обусловлено требованиями жизненного цикла. Сохраняется риск несоблюдения будущих контрактов. Выглядит красиво, но по-моему у нас так никто не делает )

Принцип фокусировки Можно разделить модели по их назначению: 1. Архивирование знания Запишем сюда всё, для последующей отчуждаемости. Жаль не работает, так как поддерживать такие модели в актуальном состоянии - адов труд. Вся эта документация по факту теряет актуальность на третий день после написания. 2. Коммуникация Эти модели строятся под заказ и под заказчика. Ориентированы на аспекты интересные стейкхолдеру. Должны быть просты и доступны. Чаще всего одноразовы. Показали и спрятали в ADR для истории. 3. Модели для моделирования То, что я использую для принятия архитектурного решения. Объективизация мысли. Такие модели подобны зрительным образам. Мозг схватив пару важных деталей сам достроит недостающую картинку. Но если заметит аномалию, или что-то непонятное, то глазу придётся сфокусироваться. Фокусируемся на непонятном и сложном. Зачем мне в сотый раз описывать таблицу логов ? )

Модель должна быть настолько простой, насколько это возможно, но не проще, чем нужно, чтобы принять следующее важное решение Пишу доку для развёртывания системы на одной солидной платформе. Требуется девятнадцать документов с моделями и расчётами. И тут на…

Модель должна быть настолько простой, насколько это возможно, но не проще, чем нужно, чтобы принять следующее важное решение Пишу доку для развёртывания системы на одной солидной платформе. Требуется девятнадцать документов с моделями и расчётами. И тут на глаза попадается заметка: В МИ-6 под прикрытием работал агент советской разведки Ким Филби. Вот его воспоминания: «Благодаря мне сотрудники первого главного управления КГБ СССР могли работать в Великобритании, как говорится, в полный рост, так как сотрудники контрразведки Ми-6 были мной отвлечены на написание никчёмных бумажных справок и отчётов. Когда кто-то из них начинал активно вести работу, вербовать агентуру, выявлять резидентов, я заваливал его никому не нужной бумажной рутиной, и его активность очень быстро сводилась на нет. Я горжусь тем, что лично разработал и ввёл несколько новых форм отчётов».

Выносливость как заинтересованность Продолжаю делиться слайдами

Архитектурное айкидо Существуют два противоположных мнения, которые уживаются в одних и тех же методичках: — Архитектура обслуживает бизнес. — Архитектура ищет баланс между потребностями стейкхолдеров. Можно объединить эти два «непримиримых» утверждения: Архитектор использует энергию бизнеса на пользу другим стейкхолдерам. Неважно, какие цели преследовал Иван IV, выделяя деньги на строительство Покровского собора. Храм Василия Блаженного до сих пор радует глаз.)

Быстрота как заинтересованность Слайды из курса по проектированию высокопроизводительных систем. Телеграм закрыли, теперь можно выкладывать )

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

ИИнтуиция Интуиция — это способность подсознания соединять разрозненные сигналы и опыт в целостное решение. Сила: учитывает то, что разум не замечает, и быстро схватывает целое. Человек чувствует, что собеседник врёт, хотя «логических доказательств» нет — сработали микродвижения и интонация. Слабость: может ошибаться, делая выводы по верхам. Игрок в покер «чует победу» и делает ставку, хотя шансы (по теории вероятности) минимальны. ИИ — это скорее искусственная интуиция: блестяще решает сложное, но может тупить на простом. Найдет патологию по флюрографиям, но ошибётся в подсчёте лап у котика. Может ли ИИ заменить разработчика/архитектора? Оставлю вопрос открытым )

Закон Фолкленда Если нет необходимости принимать решение - не принимай его.

Правильные (М/м)икросервисы Типичный разговор разработчиков: - Я пишу микросервисы, могу ли я связать их через общую базу? - Конечно нет. Левис и Фаулер запрещают (https://martinfowler.com/articles/microservices.html). - А кто такие эти Левис и Фаулер? - Гм. Ну вообще-то создатели термина "Микросервис". - А у меня своё понимание термина "микросервис". И мои микросервисы будут общаться через общую базу! ____ Кто из двух разработчиков прав? Очевидно оба ) Обычно "говорящие словами" не заморачиваются и не вспоминают тот факт, что слово может быть либо концептом, либо термином. Концепт — это слово, за которым в нашем сознании стоит целое представление со всеми его ассоциативными связями. Термин — это слово, за которым стоит определение, чётко ограниченное понятие пригодное для научного моделирования. Микросервис, как термин, ограничивает небольшое подмножество во множестве микросервисов (концепт). Тот, кто мыслит терминами, сталкиваясь с тем, кто мыслит концептами, морщится от нечёткости и нелогичности произносимого. Тот, кто мыслит концептами, считает первого душнилой. Онтологически обоснованный подход заключается в следующем: 1. Вне контекста размышляем, используя концепты (широко). 2. В контексте домена (предметной области) концепты должны стать терминами (определиться). 3. Современная онтология предполагает, что в разных доменах конкретный концепт может получить отличное определение продиктованное условиями задачи и банальным прагматизмом. При этом каждое определение, в данном случае, это выраженный архитектурный принцип. И прежде чем его дать, нужно задуматься, а сможете ли вы его поддерживать )

👆Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture Если вас интересует аспект безопасности при проектировании, советую обратить внимание на эту книжку. Тем более, что на сайте авторов её можно получить бесплатно 😊

Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture https://curity.io/cloud-native-data-security-oauth/

ИТ конференции Что-то не то показывают на наших конференциях. Обычно нам радостно демонстрируют истории успеха. При этом не всегда понятно, что является его причиной. То ли новый инструмент, то ли мастерство команды, то ли звёзды так сложились. Мы же все учимся не на успешных кейсах, а на ошибках. И умные, и дураки признают, что опыт сын ошибок. Хочется видеть истории провалов. Хочется получить демонстрацию всевозможных граблей. По статистике 40 процентов проектов завершаются либо провалом, либо превышением всех возможных бюджетов. Неужели нечего показать?

Коллективный архитектор Идея коллективного архитектора не покидает головы менеджеров. Идея интересная и у меня есть пара любопытных патернов миграции: 1. Лоботомия. Превратит любого обычного архитектора в коллективного. 2. Разделение знания. Разрезаем диаграграмы оставленные обычным архитектором и раздаем их разработчикам. Пусть выучат. #сарказм

AI как кодер Как-то искал подходящую утилиту для автоматизации надоевшей рутины. Спросил у AI и он предложил неплохой выбор, но предупредил, что сам на питоне может написать намного лучше. И я повелся ) Я по очереди использовал разные популярные модели и в итоге утилиту мы почти дописали,) За одно обратил внимание на пару нюансов: 1. Разжевывать надо тщательнее, чем даже джуну. К сожалению, то что кажется очевидным, неочевидно ИИ. У него другая "культурная" среда. Например, при выводе списка файлов лучше показывать пути а не inodes 2. Короткая память требует постоянного повторения того, что уже проговаривали. В противном случае классическая ситуация "нос-хвост". Примерно так: исправь этот дефект, но не воспроизведи тот, что мы исправили на предыдущем шаге. 3. Кинуть задачу и забыть - это не про ИИ. С ним надо сидеть в паре. И конечно же разбираться в том, что он творит. 4. Если ИИ чего то не знает - он придумает. Например, название несуществующей функции несуществующей библиотеки. И даже подкрепит это цитатой из несуществующей доки. Можете умолять его не делать этого. Он с удовольствием проигнорит самый конкретный промпт. 5. Через некоторое время свое творение он начнет называть "вашим кодом", и указывать вам на многочисленные ошибки. Это конструктивно, но раздражает. 6. Явного лидера среди моделей не выявил. Но если результат работы одной давать на растерзание другой, получается лучше, чем если все время пытать одного из них.

Реальная угроза 1. ИМХО, основным путём разработчика в архитекторы был путь перехвата управления: Амбициозный разработчик навязывался в помощники опытному, но ленивому коллеге, брал на себя все рутинные задачи и со временем "отжимал" проект (see "strangler pattern"). 2. Теперь же рутиной занимаются синий кит и ко. У молодых разработчиков больше нет шанса ( #доля_шутки