Вчерашнее обсуждение архитектуры решений (Solution Architecture) ожидаемо привело к обсуждению архитектуры предприятия (Enterprise Architecture, EA).

Напомню, что я посетовал на скудность материалов по архитектуре решений и как тут не вспомнить про их изобилие про архитектуру корпоративную. Может и не надо никаких специальных материалов по архитектуре решений и достаточно взять, например, TOGAF EA Practitioner's Guide где в разделах Walk Through Architecture to Support Project или Walk Through Architecture to Support Portfolio даны рекомендации по адаптации процесса разработки архитектуры для проекта и портфеля соответственно. Как думаете?

Как так выходит, что практически любая архитектура вдруг становится частью архитектуры предприятия? Вот готовит бизнес-архитектор или солюшн своё описание, а затем приходит архитектор предприятия и говорит, что теперь это описание стало частью архитектурного ландшафта.

Нет в этом ничего удивительного. В архитектуре предприятия такому развитию событий способствует много вещей и, в частности, концепция архитектурного ландшафта (EA Landscape). Если мы заглянем в раздел 3.2.1 Introduction to the EA Landscape руководства TOGAF ADM Practitioners’ Guide, то узнаем про эту концепцию следующее:
- не существует единого описания архитектуры предприятия
- в любой момент времени типичное предприятия использует для решения своих задач различные по широте, детальности, времени достижения и актуальности описания (см. рисунок)
- каждый проект развивает ландшафт ограниченно, в необходимом для достижения целей проекта объеме
- ну, а EA Landscape представляет собой полный набор всех архитектурных описаний

Сконструирована эта концепция таким образом неслучайно. EA изначально была нацелена на то, чтоб не только стать инструментом идентификации и организации изменений на предприятии, но и объединить собой все прочие архитектуры

Archimate форум из The Open Group продолжает придумывать всякие разные инициативы. Месяц назад я про мультик рассказывал. Теперь вот они зовут в свое сообщество поделиться и пообсуждать паттерны: https://blog.opengroup.org/2023/11/21/the-archimate-patterns-library-what-is-it-and-how-to-contribute/

Ну как не поделиться такой веселой заметкой про Circuit-Breaker Pattern https://lab.scub.net/architecture-patterns-the-circuit-breaker-8f79280771f1

Похоже, тут новый манифест архитекторов появился. Последим за реакцией https://www.thefrugalarchitect.com/

Два видео в тему. Вчерашний кейноут собственно от Dr. Werner Vogels на AWS re:Invent 2023 на пару часов:
https://youtu.be/UTRBVPvzt9w и от Владимира Иванова на час покороче: https://youtu.be/yRkayvvzX7Q

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

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