Системный сдвиг

Залез в mermaid.js по какой-то надобности, а он теперь mermaid.ai, весь такой ИИ-интегрированный. Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально. Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься). Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне. Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается. Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..) Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API. И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate? В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло. А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?

Помните карту с 162 атрибутами качества программных систем? У нас для качества требований столько не наберется, но вот ученые в эмпирических исследованиях обнаружили 111 (не знаю, как они считали, у меня получилось 89, но всё равно впечатляет!) Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся. Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно. Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало. Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности"). Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна. Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает... Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то. Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований? С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных. Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года. Перевод мой авторский, замечания принимаются. График построен в https://www.rawgraphs.io/

Меня иногда спрашивают — откуда я беру темы и как ищу неожиданные ракурсы. В основном из смежных областей. Всегда бывает интересно послушать, какие нашли решения похожих проблем в других индустриях. Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь. Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем. Вот смотрите: 1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми. 2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций. 3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом. 4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба. 5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто. 6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное. [...] 8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить. [...] 13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.» 14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается. 15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили. 16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно. 17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере. 18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке. Продолжение тут

Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом? Можно отследить изменения требований, их источники и влияние на проект. И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса". Авторы указывают следующие источники изменений в требованиях: * Рынок (включая сюда регуляторные требования); * Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата; * Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы; * Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований); * Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения. К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов. В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект. Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями. По источникам на разных этапах они распределились так: — этап требований: 30 — организация; 22 — спецификация; 15 — концепция. — этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок. — этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция. — этап приемки пользователями: 102 — спецификация; 7 — концепция. В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34). Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали). Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика. Стоимость задержки по источникам изменений и этапам, по убыванию: 1. Изменения спецификации на этапе приемки пользователями: 737 дней(!) 2. Изменения организации на этапе требований: 638 дней 3. Изменения концепции на этапе требований: 266 дней 4. Спецификация на этапе разработки: 222 5. Спецификация на этапе требований: 194 6. Концепция(!) на этапе приемки пользователями: 163 (!) + по мелочи Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки. Делаем вывод: отложенный фидбэк — путь к запланированным переделкам. Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать. Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований. В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.

Так, что-то каникулы канала неожиданно затянулись. Уже и новый год прошел, и старый, и день святого Валентина, и китайский Новый год начался, совмещенный с Масленицей. Кажется, такой паузы я ещё не делал. Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты. Но ничего, будем понемногу разбирать ёлку восстанавливать ритм публикаций. Нести свет просвещения в области системного анализа. Надеюсь, вы скучали. Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.

Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО". Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность. Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными". Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности) Вот что получилось. Влияние на личную креативность: Усиливает: - Генерацию идей - Объединение идей из разных областей - Быструю проверку/отладку - Тщательный подход - Понимание стейкхолдеров - Выбор подходящего варианта Делает устаревшим и ненужным: - Различие в личных качествах - Глубокое мышление - Рефлексию - Экспертизу - Менторинг Возвращает: - Эскизное проектирование, наброски - Верификацию - Творческую работу Приводит к обратному: - Штамповке типовых решений - Исключению анализа вариантов - Потере креативных навыков Влияние на продукт: Усиливает: - Непрерывное улучшение - Кастомизированный UX - Учет обратной связи - Возможность делать "невозможные вещи" - Радикальные инновации Делает устаревшим: - Стандартные решения - Фреймворки - Промежуточные артефакты проектирования - Графический дизайн и элементы оформления - Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.) Возвращает: - Паттерны и стили - Старые приемы проектирования и решения - "Аналоговые" методы проектирования — на карточках, на бумаге Приводит к обратному: - Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов - Однообразные продукты - Чрезмерно креативным, вычурным продуктам - Предвзятости - Вредным продуктам, черному UX, эксплуатации аддикций Влияние на процессы: Усиливает: - Обыденные задачи - Быстрое прототипирование - Коллаборацию - Креативность по запросу - Модерацию/фасилитацию Делает устаревшим: - Мозговые штурмы - Специализацию, разделение ролей - Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.) - Экспертов по креативным методикам и проектированию Возвращает (тут всё в противодействие): - Парное программирование - Техники генерации идей (мозговые штурмы, дизайн-спринты) - Аналоговые техники творчества (лего, бумажное прототипирование и т.п.) - Ручные исследования пользователей - Изучение других предметных областей Приводит к обратному: - Потере интуиции - Потере доверия - Потере работы - Разложению ролей специалистов по созданию ПО - Кафкианской безответственности Влияние на среду: Усиливает: - Поиск контекстной информации - Вдохновение окружающей средой - Сборку команд - Эффективность в виртуальных средах - Психологическую безопасность - Голос разума - Готовность принимать риски Делает устаревшим: - Доски, флипчарты, стикеры - Кубиклы - Фиксированные пространства - Офисы вообще - Коллег Возвращает: - Креативность в движении - Поддерживающее руководство Приводит к обратному: - Саботажу - Изоляции - Снижении гордости за результаты своего труда - Давлению руководства - Невозможности высказаться - Ненужности креативности Ну что, как вам такие предположения?

С наступившим Новым годом! В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика! Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто! Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!

Нужно, наверное, какие-то итоги года подвести. Итоги такие: 1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно. 2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском). 3. О чем писал: * Сильно обновил карту интеграций: раз и два * С какими видами неопределенности работает аналитик и что с ними делать? * Экономическая обоснованность автоматизации задач * Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках") * Вытащил в наглядную таблицу пример стоимости масштабирования * Перевел несколько комиксов про разработку * Написал про формулу Пуассона для расчета нагрузки в интеграциях * Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения * Запостил "Пирамиду требований", которую обычно на тренингах рисую * Написал про эмоциональный компонент JTBD * И про "Ясный язык" * Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности * Провел небольшое исследование — про среду в компаниях по методу Ясвина * Про радар выбора процесса разработки — подходит ли для вашего проекта Agile? * Какие решения и в каком виде можно передавать ИИ? * Нашел граф со всеми возможными нефункциональными требованиями * А ещё — каталог паттернов миграции со старой системы на новую * И шаблон для PRD * Сходил на новые конференции от JUG.ru — BiasConf и InBetween * Пошутил про приколы интеграции (не протоколы!) * Подсмотрел, как живут продакты (по отчету Atlassian) * Поучаствовал в проектировании и анализе исследования системных аналитиков * Завел отдельный канал про цифровизацию образования * Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками * Затеял несколькопостов про DDD * И вообще про роли аналитика и архитектора: раз, два и три * А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять. А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память). В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо. С наступающим Новым годом! 🎄🎁🥂🎆

Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю. В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь). Дальше они характеризуют разные уровни рассмотрения: — требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям; — архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования. — проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований. — реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода") Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!) Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент. Итак, авторы определяют архитектуру через три понятия: Software Architecture = { Elements, Form, Rationale } Элементы архитектуры делятся на три класса: * элементы обработки * элементы данных * соединительные элементы Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой. Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR. Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить. Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.

Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО? Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов. Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась. В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов. Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах). В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула: Программная архитектура = {Элементы, Формы, Обоснования}, где Элементы делятся на элементы обработки, элементы данных и элементы связи, а Формы — на взвешенные свойства элементов/системы и отношения между элементами. В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает. В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего. Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем. Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.

Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку). Разделы: Название Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы. Стратегическая классификация, из трех частей: 💎 Уникальность — насколько этот контекст важен для успеха организации? Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического? ⚙️Роль в бизнес-модели: — генерация прибыли, — повышение вовлеченности/виральности, — предотвращение рисков (регуляторных, репутационных, ...) — снижение расходов 📊Стадия эволюции (по Wardley map): — Зарождение — Заказная разработка — Готовый продукт — Типовое решение (commodity) Архетип домена (роль): — Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта) — Исполнитель (выполняет или поддерживает исполнение бизнес-процесса) — Аудитор (отслеживает выполнение) — Контролер (принимает решение о возможности выполнения следующего шага, утверждает) — Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами) — Переводчик (переводит между разными "бизнес-языками") — Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика) — Пузырь (экранирует легаси-систему до её вывода) — Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой) — Аналитика (собирает и обобщает данные) Язык домена: какие в этом контексте есть понятия и термины? Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события. У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста: — OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст. — CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream. — ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне. — SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание. — PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться) — Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития. — PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR. По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне. Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы. Бизнес-решения: какие приняты решения, политики и бизнес-правила. Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались. Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех? Открытые вопросы: что ещё нужно выяснить? Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.

Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано. Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два. Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить? Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики. Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите: 1. Идентичность и ответственность 1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс». 1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.). 1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис 2. Границы и связи с другими сервисами 2.1. Для сервиса понятен список use-case’ов, в которых он: — ведущий (владеет бизнес-логикой), — участник (вызывается другим сервисом, реагирует на событие). 2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события. 2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми". 2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех. 3. Данные и инварианты 3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук). 3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться" 3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия) 3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных) 3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие). 3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории 3.7. Приняты решения по модели чтения (CQRS, Event Sourcing) 4. Контракты, схемы и API 4.1. Составлен список внешних операций: — команды (изменяют состояние), — запросы (чтение), — доменные события (что сервис публикует). 4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API. 4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки: — ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency), — какие — технические, — как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку). 4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем 4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка 4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности 5. Надёжность, производительность, наблюдаемость 5.1. Для ключевых операций определены SLO: — латентность — доступность — процент ошибок 5.2. Поведение при отказах: понятно, что делает сервис: — при падении зависимого сервиса, — при перегрузке (ограничение, деградация, очереди), — есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок 5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам 5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке 5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования