Базовая методология по программной архитектуре

На прошедшей конференции меня часто спрашивали:
какую методологию я порекомендую архитектору ПО.

Опубликую свой ответ здесь.

Я считаю базовыми знаниями - знания практик от института SEI.

Многие методологи ссылаются на методы SEI.
ATAM, ADD и др. упоминаются во многих работах, в том числе TOGAF.

Многие курсы по архитектуре базируются на курсах Рика Казмана из SEI.
Сам преподавал по Kazman Workshop в Люксофт )

Большое количество материала здесь - https://www.sei.cmu.edu/publications/index.cfm

Базовая методология

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

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

Примерно так же это сделал небезызвестный Eoin Woods:
Взял от SEI метод ATAM и настроил его под себя назвав TARA.

2. Почему за базу беру практики SEI?
a. Они достаточно популярны и много где упоминаются.
b. Эти практики имеют хорошее покрытие по активностям программного архитектора.
c. Эти практики хорошо документированы.

3. Использую ли я методологию SEI в ее "классическом" виде?
Нет.
Слишком тяжела для большинства кейсов.

Так что: "после сборки обработать напильником" )

Обучение архитектуре

По последнему докладу получил следующий комментарий:

"Автор предлагает для принятия решений предварительно ознакомиться с огромным количеством теоретической информации. Но часто принимать решения нужно сейчас, а не через год изучения теории."

Так как не могу ответить лично, отвечу здесь.

Для принятия архитектурного решения года изучения теории явно недостаточно.

Я бы сказал от пяти лет. При этом активно сочетая с практикой.

Я не буду толерантно называть это "моим мнением".

Зафиксирую это как факт.

Инженерная школа
(Ворчалка)

1. Не прекращаются споры о том, чем должен заниматься в проекте архитектор/аналитик/программист etc.
2. Вопрос легко решается в рамках одного проекта. Но на общих площадках согласия нет. Идут баталии.
3. Я вижу причину в том, что традиции русской школы программной инженерии во многом утрачены.
4. Где под школой я имею ввиду не только совокупность методов, но и традиции, культуру, организованную преемственность.
5. Старые инженера-программисты, носители культуры остались в почтовых ящиках и большей частью не пошли в бизнес проекты.
6. На смену пришли молодые. Всё с нуля. Источник знаний - инет. Методология эклектична. Культура? А зачем она вообще!
7. Возможно все утрясётся и устаканится. Под термином "программный арх." везде будут понимать одно и тоже. ГОСТ по архитектуре будет не слабым переводом ИСО, а собственным выстраданным, творением. Возможно, но не факт.

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

Architecture Through Different Lenses

InfoQ опубликовал книжку (mini-book) Architecture Through Different Lenses.

К сожалению, не доступна для скачивания из нашей локации.

Выложу здесь)

Оптимизация времени отклика с переворотом

1. Задача оптимизации производительности чаще всего сводится к оптимизации пропускной способности (Throughput, X) или времени отклика (Response Time, R).
Смотрите например у М.Фаулера "...под производительностью можно понимать один из двух параметров — время отклика или пропускную способность...".
2. Оптимизация начинается с локализации проблемы. Нужно найти проблемный участок и оптимизировать его. В противном случае на оптимизацию всей системы вы потратите слишком много ресурсов.
3. В случае пропускной способности проблемный участок находится легко (сравнительно). Этим участком является бутылочное горлышко системы. (Смотрите на эту тему QNM или ТОС).
То есть участок системы с максимальной потребностью в обслуживании (Service Demand, D).
4. Случай оптимизации времени отклика намного сложнее. Но есть один трюк:
- Время отклика задается для определенной нагрузки (R для X)
- Выворачиваем схему. Находим X0 при котором RT удовлетворительно и оптимизируем X (пропускную способность)
- Сводим задачу к "простому" поиску бутылочных горлышек.

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

#Производительность

Представление vs Модель

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

Я считаю такие "терминологические" споры бессмысленными.
Это примерно как спорить о смысле термина "Account", приводя определения из разных доменов (привет Эвансу). В доменах "Авторизация" и "Банк" эти сущности имеют разные смыслы.

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

Представление vs Модель (2)

В моём архитектурно-методологическом домене картина такая:

1. Представление и модель (в терминологии ИСО/ГОСТ) - суть оба модели. То есть предоставляют знание о проектируемой системе.

2. Модель (model) это "Big Data", llm системы. Накапливается непрерывно. Включает онтологию и структуру сущностей. Чаще всего это ментальная модель, но может быть оцифрована.
Назначение: накопление данных для формирования ответов на еще не заданные вопросы стейкхолдеров. Связывание и аппроксимация.
Характеристика: сложная, не чёткая.
Аналогия с данными: Озеро

3. Представление (view) это ответ на заданный стейкхолдерами вопрос. Выражено определенной нотацией. Объективизировано и материализовано.
Назначение: Закрыть потребности стейкхолдеров.
Характеристика: предельно простая, ясная и консистентная модель.
Аналогия с данными: Ответ на запрос.

4. Точка зрения, аспект (view point) это часть модели заточенная на конкретного стейкхолдера.
Назначение: Ограничение большой модели, выделение в большой модели независимых ограниченных контекстов.
Характеристика: большая, но консистентная модель.
Аналогия с данными: Витрина.

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

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

На втором этапе архитектор на базе накопленных знаний формирует новые модели (проектирование) и представляет их стейкхолдерам (документирование).

Представление vs Модель (3)
Практические выводы.

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

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

Что я собираюсь зафиксировать на этой диаграмме: model, viewpoint, view?

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

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

3. View отвечает на конкретный запрос пользователя. Не стоит забивать его деталями не относящимися к запросу.
Ясно и лаконично.

Общий анти-паттерн - смешение на диаграмме view и viewpoint моделей.
Ответы на вопросы с большим количеством избыточной информации.

Безопасности с нулевым доверием (zero-trust security model)

Редко пишу про безопасность. Однако это тоже архитектурно значимое качество.)

Здесь мой чеклист начинается с определения того, что охраняем.
Варианта два:
1. По старинке, охраняем периметр.
2. Охраняем каждый сервис (zero-trust security model).

Второй случай жуткий, но даже при использовании Docker можно кое-что предложить.

1. Docker Desktop
- Air-gapped containers в Docker Desktop version 4.29.0
Независимое конфигурирование безопасности каждого сервиса.
- Драйвер Macvlan, который позволяет рассматривать контейнеры как физические устройства с разными MAC-адресами
2. Kubernetes
- тут я знаю только service mesh

Возможно, Вы сталкивались с этой проблемой и сможете дополнить мой крайне короткий список)

Enterprise Security

К слову о безопасности.
На DZone вышел очередной сборник Enterprise Security (август 2024).
- Тут, как обычно, опрос с учетом угроз OWASP.
- Хорошая статья про упомянутый выше "Zero Trust".
- Замечательный материал по построению модели угроз "Full-Stack Security Guide"

В общем рекомендую )

Серьезные дискуссии
(ворчалка)

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

Господа, пора переходить на llm.
Обсуждение не будет серьезным, если мы не дадим слово AI.

Говоря серьезно, устал от пустых обсуждений с перебором случайно обнаруженных вариантов.
Хочется видеть классическую постановку задачи. Декомпозицию задачи на подзадачки и основательное обоснованное решение.
Разучились?

Все доклады в одном месте

В связи с замедлением ....

Собрал всё в одном месте
https://vk.com/video/@id83992027

Архитектурная проблема

- Как исследователь, я должен подвергать сомнению любое свое решение.
- Как руководитель, я должен продвигать свое решение, как несомненно верное.
- Не успеваю переключаться (

Балансировка нагрузки

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

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

1. Балансировка нагрузки не важна
Нет, если вы предполагаете масштабировать систему по нагрузке. Несбалансированная система не масштабируется.
2. Балансировка не имеет смысла, если один сервис способен вытянуть всю нагрузку
Нет,
- если нагрузка высока, то есть высока вероятность попасть в очередь.
- если ваша нагрузка не представляет собой строго периодическую подачу одинаковых запросов.
- если вы не исключили все возможные "шумы" со стороны.
Любой всплеск породит рост очереди, которая может никогда не рассосаться. Это сразу ухудшит перцентили по времени отклика. Хуже того, рано или поздно в это состояния перейдут все сервисы.
3. Сервис Kubernetes справится с балансировкой без нашего вмешательства.
Нет. Сервис кубера - эфемерная штучка. По умолчанию нагрузкой управляет IPTables, используя правила полученные от kube-proxy. Любой входящий коннект намертво привязывается к случайному поду.
4. Случайная/карусельная балансировка вполне подойдёт для высоконагруженных систем.
Нет. см. п.2.
5. Под кубер для балансировки лучше всего использовать Service Mesh (Istio)
Нет, если Вам дороги ваши ядра )
Если вы уже используете Istio, то логично использовать его возможности по балансировке. Если же нет, то намного логичнее заюзать возможности ОС (IPVS).
6. Предлагаемые из коробки алгоритмы балансировки оптимальны (см. Istio (least request) и IPVS (least connection))
Нет. Хуже того, "идеального" алгоритма не существует. Для каждого сервиса оптимальным будет являться алгоритм учитывающий особенности этого сервиса и особенности нагрузки. В большинстве случаев алгоритм least request/connection дает приемлемый (удовлетворительный) результат.

Извините, что много букв )

Кто кому модель?

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

Архитектура это первая формируемая Система.

И тогда система это компьютерная модель уже существующей архитектуры.

Часто хреновая модель )

Архитектура архитектуры

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

Контекст (зачем и кому нужно?)
Система: Архитектор
Акторы: Стейкхолдеры реализуемой системы
Основной сценарий: Стейкхолдеры получают ответы на вопросы по реализуемой системе (технологии, структура, поведение, ожидаемые качества и т. д.)

Информационное представление (что оно такое?)
- Для ответа на вопросы архитектор строит архитектуру (tobe) как некоторую модель (модели) будущей системы.
...
____________________

Часто задаваемые вопросы:

1. Нужен ли архитектор?
Сложная архитектура, включающая большое количество деталей и зависимостей с окружением очень сложно объективизируется. Для сложной архитектуры естественной средой обитания является мозг.
Вывод: в более менее сложных системах для прогнозирования структуры и поведения системы нужен архитектор (или ИО)
2. Может ли быть архитектором неопытный специалист?
Сложная ментальная модель может эффективно использоваться при наличии в сознании архитектора устоявшихся абстракций. То есть все сложные структуры должны быть привязаны к хорошо продуманным понятиям. Оперировать этими понятиями намного проще.
Вывод: архитектор должен быть опытным, со сформировавшейся понятийной моделью.
3. Можно ли размазать роль архитектора по команде?
Архитектура может быть представлена на нескольких носителях (умах). Но в этом случае требуется обеспечить когерентность данных, иначе мы получим несколько вариантов архитектуры одной системы.
Вывод: распределение архитектуры не будет приводить к противоречиям, если мы декомпозируем ее на несколько частей и распределим по частям. Репликация архитектурной модели чревата неприятными последствиями.
4. Как передаётся архитектурное знание?
Отчуждение архитектурной модели не возможно без потери информации. То есть архитектурное представление не полно отображает породившую его модель.
Вывод: чем лаконичнее архитектурное представление, тем более оно нуждается в сопровождении архитектора.

Архитектура архитектуры (аспекты)

Коллеги, спасибо всем кто принял участие в голосовании/обсуждении.

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

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

Для затравки хочу привести точку зрения стандарта (argumentum ad verecundiam).

Итак ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011

1. Эфемерность архитектуры
Архитектура не эфемерна. Она "представляет собой абстракцию, состоящую из понятий и свойств".То есть как минимум это определённый информационный продукт.
2. Архитектура как описание
Архитектура не тождественна своему представлению.
"Настоящий стандарт отличает архитектуру системы от описания архитектуры".
Где описание архитектуры это совокупность ее представлений.
3. Архитектура как свойство системы
Архитектура связанна с системой, но не является ее свойством (атрибутом).
Любая система имеет архитектуру. Но обратное не верно. Архитектура может существовать без реализованной системы. Более того здесь связь многое ко многому:
"Та же самая система может быть понятной с помощью несколько отличающихся архитектур (например, когда они рассматриваются в различных окружающих средах).
Та же самая архитектура может характеризовать более чем одну систему (например, семейство систем деления какой-то общей архитектуры)."
4. Приземление архитектуры
Стандарт относится к описанию архитектуры и мало что говорит про архитектуру саму по себе.
Однако, зафиксировав изложенные факты
- архитектура это информация
- архитектура не тождественна своему описанию
- архитектура не атрибутивное свойство системы
Можно сделать вывод:
Из положений стандарта следует что информационный объект архитектура может быть физически приземлён...

Не буду делать вывод.
Оставлю диаграмму развёртывания на ваше усмотрение )

Архитектура архитектуры (историческая ретроспектива)

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

2. На моих глазах инженерия деградировала. Нехватка времени/сроков приводила к тому, что многие проекты стали менее детальными. Инженера срезали углы. Многие разделы писались для галочки - от балды.

3. В скором времени этот подход узаконили. Принимали только основные решения: структура, контуры системы, тех. стек и т. п. Тут и появилось модное западное словечко "архитектор".

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

5. Конкуренция росла. Требования по срокам/деньгам становились жестче. И вот уже аджайл выдвинул лозунг: "никакого предварительного проектирования". Но это уже другая история...

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