Очень короткая и простая история про команды, запросы и события https://youtu.be/G9LjwV8yDZU?si=79xMz21ok9q2czY_

📆 27 декабря 10:30 MSK
Уже традиционный и абсолютно бесплатный стрим по Архитектуре решений (Solution Architecture) с ответами на ваши вопросы.

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

Подробности и регистрация здесь: https://mxsmirnov.timepad.ru/event/2717600/

Запись: https://youtube.com/live/_GKNhoPmZYI

Короткий текст и несколько ссылок у меня в блоге: Архитектура данных в архитектуре решений

Дорогие друзья!
Поздравляю вас с наступающим 2024-м! Желаю здоровья, счастья и всего самого-самого наилучшего вам и вашим родным!

С Новым годом! 🍾🎄🎉

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

Это было бы еще одним текстом о том, какими бывают ИТ-архитекторы, если бы не попытка автора привязать разные виды архитектур к разным диаграммам из C4 Model (картинка внутри). Идея в данном конкретном вопросе, на мой взгляд, так себе. Хотя искать различия, обусловленные точками зрения стейкхолдеров – вполне себе архитектурный подход https://lab.scub.net/the-different-types-of-software-architects-c4-model-perspective-dcf3bb4c49e8

Краткое описание к advanced integration patterns здесь: https://www.enterpriseintegrationpatterns.com/ramblings/80_syncorswim.html
Исходная заметка Ivan Gevirtz о визуализации потока управления http://www.ivanism.com/Articles/SinkorSwim.html

Почему люди перестали использовать варианты использования?

В опубликованном в ноябре прошлого года тексте Ивара Якобсона и Алистера Коберна (которых, я думаю, не надо дополнительно представлять) приводятся следующие три фактора:
1. Тенденция делать из описания варианта использования настоящую энциклопедическую статью
2. Написание вариантов использования требует исследований и размышлений
3. Появление пользовательских историй. (Отдельная часть статьи – размышления о сильных и слабых сторонах user stories)

Полный текст здесь: https://queue.acm.org/detail.cfm?id=3631182

Дополню это сообщение чуть более ранней ссылкой https://queue.acm.org/detail.cfm?id=2912151

Здесь немножко про историю вариантов использования, их позиционирование(на мой взгляд, неверное, как и в предыдущем тексте) и шесть принципов подхода, и названного Якобсоном Use-case 2.0

Короткая заметка о том, что с заинтересованными лицами ситуация чуть сложнее, чем кажется на первый взгляд: Слоёный пирог стейкхолдеров

Фаулер завершил обновление в своей bliki заметки Continuous Integration(оригинальная версия появилась в сентябре 2000, обновилась в 2006, а о переработке статьи было объявлено в октябре прошлого года). И хотя все уже давно и хорошо понимают о чем идет речь, в этом большом тексте можно найти интересные моменты.

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

Любителям традиционной архитектуры предприятия, но в формате на одной странице: TOGAF ADM - фазы и документы (из предыдущих версий)

Взял здесь: Architecture Frameworks: TOGAF, ArchiMate, Zachman & DoDAF (Там есть еще ряд интересных вещей)

Что почитать в выходные

Недавно в чате про архитектуру в очередной раз случилось обсуждение систем, а чуть раньше, в начале января, у Грэма Беррисфорда появилась пара новых больших текстов про сходства и различия в понимании систем в архитектуре предприятия, кибернетике и системной динамике.

Лучше начинать читать отсюда On human knowledge В конце текста больше дюжины ссылок на другие его тексты вокруг систем.

Можно начать и с этого текста How EA departs from cybernetics, но будет сложнее. В любом случае, читать Грэма проще, чем разгребать первоисточники (Хотя на некоторые из них ссылки есть прямо в тексте)

В нашем чате Работа для ИТ-архитекторов новое обсуждение ролей и зон ответственности: архитекторы, тимлиды, техлиды и пр. Кто нужен, кто не нужен, зачем, когда, где… - прям матрица Захмана. Кстати, именно классификации типов ролей в индустрии, на мой взгляд, и не хватает. Разного рода SFIA они плоские, если так можно сказать. В них нет принципиальных различий между разными ролями.

На мой взгляд, полезней была бы многомерная модель. В ней по одной оси откладывается тип организации. Например: enterprise, outsourcing, product-based company. И в одних из них архитекторов много и разных, а в других практически нет. Ну или энтерпрайзов совсем нет, а системный архитектор - один на продукт или на технологию, как это было принято в системных интеграторах.

Другое измерение – унифицированность видов деятельности и навыков. Это можно отобразить в виде концентрических окружностей. В центре более стандартизированные роли: dev-ops-qa. Потом круг с тимлидами и аналитиками. Потом роли, которые перечни своих работ и задействованных ресурсов формируют самостоятельно и в каждой работе заново (помните в TOGAF ADM этапы B-D начинаются с выбора эталонных моделей, точек зрения и инструментов. Более общий термин для подобных вещей job crafting – подстраивание, подгонка работы под себя. Скоро об этом собираюсь рассказать поподробнее. А заодно и про модели мотивации-выгорания, JD-R и пр.). В общем, в этом измерении нужно что-то похоже на tech radar

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

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

В четверг Уэйд Уолдрон в своем видео на канале Confluent напомнил нам про Transactional Outbox Pattern. А следом Дерек Комартин вспомнил про свой прошлогодний ролик Alternative to the Outbox Pattern в сообщении Listen to yourself pattern: Is it an alternative to the Outbox Pattern?

Как спокойно было в нулевые, в мире монолитных приложений и транзакций, реализованных внутри СУБД. Хороших всем выходных!

Чем-то меня зацепил этот автореферат книжки Software Architecture and Decision-Making Может кто-то уже успел полистать и готов поделиться рекомендацией читать – не_читать?

Результаты опроса о том, что не всегда просто сделать при изложении архитектуры решения:
- Объяснять сложные вещи
- Уложиться в отведенное время
- Запоминать новые идеи
- Сдержать волнение

Однажды автор C4 model Саймон Браун подготовил A software architecture diagram review checklist.

Мне нравится С4 модель, вернувшая чересчур абстрактные подходы UML в домен информационных технологий. Мне нравятся чек-листы – простой способ направить ту или иную деятельность в нужное русло и проверить степень готовности результата этой деятельности. Но я думаю, что существует некоторая опасность, заключающая в формальном отношении к чек-листам. Это обстоятельство может все испортить.

Возьмем, например, пункт: «каждая диаграмма должна иметь заголовок» - кто бы с этим спорил. Большинство архитектурных диаграмм имеет заголовок. Значительная часть заголовков выглядит примерно так: «С4 Container Diagram». Ценность такого заголовка колеблется в районе нуля, плюс-минус. Место на диаграмме и внимание при её разборе занимает, а пользы не приносит. В кратком анонсе Браун пишет, что заголовок диаграммы должен описывать её тип и границы и в качестве примера приводит "System Context diagram for My Software System". Думаю, это не вполне подходит.

Я бы сказал, что заголовок должен привязывать диаграмму к месту, времени и автору. Т.е. мало указать диаграмму чего мы рисуем: системы, проекта или изменения. Во-первых, потому что имена вещей могут пересекаться. А во-вторых, практически всегда, абстрактные идентичности (системы, проекты и тем более изменения) имеют очень неявные границы. Под термином веб-сайт продукта может скрываться все что угодно. Далее, со временем вещи (и их границы) меняются. Да и само понятие время штука довольно сложная (вспомните грамматику любого иностранного для вас языка). Есть нечто свершившееся, нечто запланированное и что-то происходящее прямо сейчас. А есть еще наши планы, которые были сформулированы в отношении будущего и должны были реализоваться вчера, но мы не знаем случилось ли это или нет. Для описания подобных времен нужная специальная бюрократическая грамматика. Ну, да ладно. И завершающий момент: архитектурные представления (особенно представления будущего) вещь крайне субъективная. Потому без указания автора диаграмма утрачивает значимую часть своей убедительности. Иногда эта часть заголовка заменяется подписью руководителя. Впрочем, оптимальный вариант – заголовок в виде гиперссылки, ведущий на страницу описания изменения со всеми перечисленными выше реквизитами. Если это невозможно, то можно добавить пару срок с датой, автором и назначением диаграммы рядом с заголовком или в любом месте картинке.

(Много слов получилось. В следующий раз сокращу или сделаю пост в блоге)