Давайте поделюсь еще одним отчетом по #PlatformEngineering
State of DevOps Report: Platform Engineering Edition https://www.puppet.com/resources/state-of-platform-engineering

Каждая версия технологического радара приносит какие-то новые термины или переосмысляет прежние. Вышедшая на днях 28-ая версия не исключение. И в длинных списках платформ, инструментов и языков программирования может легко затеряться раздел про системы управления знаниями. Так что обратите внимание на то, что Thoughtworks включил в кольцо assess раздела инструментов Obsidian и Logseq

На AWS re:Invent 2022 знаменитый Gregor Hohpe в своем выступлении Are you integrating or building
distributed applications? порадовал нас вот таким вот слайдом про RPC

[1] Ссылка на выступление https://youtu.be/Zrj7RD7G24Q?t=3141
[2] Слайды в PDF

Можно было бы сделать отдельный курс по Solution Architecture по материалам от Alan McSweeney. Но пока этого не случилось, в дополнение к слайду о составе ИТ-решения, я поделюсь его слайдом об отображении компонент решения и зависимостей между ними

Авторы курсов по Solution Architecture (не только я :) любят делиться своими материалами. Вот, например, из Web Age Solution Architect

Мало кто сомневался, что рано или поздно холст(canvas) описания архитектуры появится. Вероятно, не первый и не последний вариант Software Architecture Canvas представил пару недель назад Patrick Roos. Описание шаблона и параллели с arc42 и c4model см. по ссылке выше и в других текстах этого автора на workingsoftware.dev

У Olaf Zimmermann (ZIO) в блоге вчера появился гостевой пост How to Build and Run a Decision-Making Architecture Board По удивительному стечению обстоятельств именно о работе с решениями в формате ADR и вынесение их на архитектурный комитет мы обсуждаем на курсе Практики архитектуры предприятия очередной поток которого закончился тоже вчера

Наверняка вы однажды задумывались - откуда взялось разделение моделей на концептуальные, логические и физические. Не знаю, кто первым придумал такое разделение, но у Zachman оно уже есть. Появилось оно еще в первых вариантами матрицы, а некоторое самодостаточное описание можно почитать здесь Conceptual, Logical, Physical: It is Simple

Многие книги, а тем более статьи, появляющиеся в наше время, пытаются свести ИТ-архитектуру к набору практичных рекомендаций. В меру простых, чтоб их несложно было растолковать широкому кругу читателей, как правило не архитекторов. В меру полезных, ну или выглядящих такими. Ну, и конечно, охватывающим достаточно широкую область общих и актуальных для самых разных организаций проблем. Таковы, например, книжки Марка Ричардса. Хотя каждая последующая из этой условной трилогии глубже и интересней чем предыдущая, все их объединяет простая идея от SEI: давайте возьмем нефункциональные требования и выберем из «списка архитектур» ту, что подходит нашему сочетанию требований наилучшим образом.

При всем уважении к институту программной инженерии и выращенному им отряду ученых компьютерных наук, выскажу свой скептицизм в отношении такого подхода. ИТ-архитектура, конечно же, не ограничивается выбором формы декомпозиции требований на отдельные слабо- или не очень слабосвязанные процессы. Что остается между строк, скорее даже за стрелками и боксами архитектурных диаграмм – тема моего следующего вебинара.

Проанонсирую его в ближайшее время!

Выложил запись https://youtu.be/fC-0SHqfFq4

Несколько нетрадиционный взгляд на микросервисную архитектуру озвучил сегодня Марк Ричардс в своем архитектурном понедельнике https://youtu.be/UZQMUiVqpFs В давней статье Льюиса и Фвулера говорилось о владения микросервисом всеми своими процессами. Марк делает акцент на изолированности данных микросервиса. Речь идет даже о владении таблицами данных в некоторой (дисковой, как я понимаю) БД. И во второй части ролика это позволяет ему предостеречь от использования микросервисной архитектуры в ситуациях, когда мы не можем выделить в наших данных ограниченные контексты. Другой причиной отказаться от микросервисов он называет сильную семантическую связанность функций (Что это?). В сочетании с картинкой зацикленных вызовов и упоминанием о большом комке грязи это уже напоминает хэллоуиновкую открытку

Транскрипт разговора с Ребекой Парсон на InfoQ https://www.infoq.com/podcasts/evolutionary-architecture-evolution/

Нет, ну я так не играю...

В Scaled Agile Framework оказывается есть своя табличка со сравнением архитектурных ролей. Где они были лет десять назад?

Хочу поделиться ссылкой на очень короткую(9 страниц) и очень простую статью о методе Enterprise Architecture Planning (он же – wedding cake) https://gc.scalahed.com/recursos/files/r161r/w24851w/updating.pdf Мне кажется, что этот текст отличная иллюстрация того, что архитектура предприятия была когда-то вещью практичной и не сильно запутанной. По сути, весь текст - пояснение этой одной картинки

От создателя Ruby on Rails, Basecamp и автора Rework [правильный]текст c кликбейтным заголовком How to recover from microservices https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc

1. Прекратите копать (проснувшись в яме)
2. Соберите свои flow
3. Сохраните обособленными сегменты систем, критичные к производительности
4. Откажитесь от наиболее эзотерических реализаций
5. Научитесь декомпозировать большие системы на модули, а не разделять их сетями

Читайте книжки Эрика Эванса, Кента Бека и Мартина Фаулера

The mass adoption of microservices...
... массовое цитирование 8 заблуждений относительно распределенных вычислений потребовало их визуализации. И вот, пожалуйста, вам картинка https://architecturenotes.co/fallacies-of-distributed-systems/ Сопровождающий эти иллюстрации текст не столь хорош, но хоть более развернутый нежели в Википедии

И еще про картинки

В тексте Modeling Complex Domains with Aggregates, Entities, and Value Objects нет ничего примечательного. Ничто, что отличало бы его от множество подобных "очень кратких рассказов про DDD для чайников". Но вот картинка про объект-значение автору удалась

Можно ли вместо OpenAPI спецификации для описания интерфейсов использовать примеры запросов и команд? Посмотрите Jsight и дайте свой вариант ответа (внутри описание, примеры и видео, а вот ссылка на большой текст на медиуме: What’s Wrong With OpenAPI?)

Переслушал свой вебинар трехлетней давности Дилемма корпоративного ИТ-архитектора (на скорости 1,25 :-) В ближайшие дни хочу сделать продолжение, которое начну с того чем закончил, т.е. с разговора о том Какие бывают архитектуры предприятия