Коллеги, спасибо всем тем, кто поделился своим пониманием цели формирования архитектуры!

Много лет я преподавал практики SA, повторяя вслед за методологами аксиому о высшей значимости бизнес цели.

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

Смысл выключателя

1. У любой системы есть смысл – цель ее существования с т. з. заинтересованного субъекта (стейкхолдера)
- Смысл делает систему системой. Т. е. не просто совокупностью элементов, а целостностью, обладающую некоторым ценным эмерджентным свойством.
2. Одна из задач архитектора – определить смысл проектируемой системы.
3. Одна из практик выявления смысла сводится к постановке "правильных" вопросов.
4. С моей т. з. самым быстрым путём к смыслу будет вопрос: "А что было бы, если бы системы не было бы?".
- Вы не задавали себе вопрос, почему выключатель называется выключателем, а например, не включателем? Ответ прост. Если бы выключателя не было бы, свет горел бы всегда. Смысл выключателя в добавлении основной функции "выключения" и вспомогательной "включения".
5. При этом ответ на этот вопрос различен с т. з. разных стейкхолдеров.
6. Основным стейкхолдером системы является пользователь , он и определяет основной её смысл.
- При этом пользователь микроскопа может определить его как инструмент для заколачивания гвоздей.
7. Как бы не были значимы интересы бизнеса, бизнес-цель это дополнительный смысл системы.
- Например, система должна приносить прибыль (нет системы - нет прибыли).
8. Интересы команд поддержки и сопровождения сводятся к возможности работать с системой.
- При этом полностью законченная и абсолютно надежная система становится неинтересной.
Забавный факт:
Многие признают, что основной смысл системы идет от пользователя, но при этом утверждают, что основная цель проекта - удовлетворение бизнес-целей. Нет ли здесь когнитивного диссонанса?

Интересная статья по моделированию производительности https://dzone.com/articles/queuing-theory-for-software-engineers

Обещанная презентация с TeachLead Conf.

Тема для доклада слишком объемная.
Но дробить на несколько докладов не стал.
Буду в канале разбирать по частям.

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

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

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

Я считаю базовыми знаниями - знания практик от института 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