Excalidraw пытается рисовать диаграммы, описанные на русском языке начинающим промптером

Если вы любите большие пространные рассуждения про CAP теорему и согласованность данных в распределенных информационных системах, то длинный текст Марка Бёрджесса Deconstructing the `CAP theorem' for CM and DevOps безусловно для вас.

Со списком литературы и в двух частях:
Part 1: The Special Theory of Relativity for distributed systems
Part 2: The greatest distributed system of them all

Еще в октябре вышла новая книжка автора экстремального программирования Кента Бека Tidy First?: A Personal Exercise in Empirical Software Design
Книжка маленькая – 125 страниц. Практически, это набор из 33 небольших заметок, разбитых на три группы: tidyings, managing, theory. Но писал её Бек 3,5 года. А в прошлогоднем выступлении на QCon plus он рассказал, что это первая книга в серии из трех. Еще не вышедшие книжки расскажут о взаимодействии внутри разработчиков и разработчиков с заказчиками

Очень короткая и простая история про команды, запросы и события 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

В чем различие между проектированием распределенной системы и интеграцией различных приложений?

Новый вид ИТ-архитектора - appligration architect появился в конце прошлого года на выступлении Gregor Hohpe и Dirk Fröhner Advanced integration patterns & trade-offs for loosely coupled systems на AWS re:Invent

Ремарка: У них прямо настоящая лекция получилась; с разбором простого примера и рассказом о паттернах, которые не попали в книжку про EIP.
В общем, всё как мы любим. Ну, может быть чересчур просто

Слайды можно скачать/посмотреть на этой странице: https://s12d.com/api309-2023

Краткое описание к 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?

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