Несколько нетрадиционный взгляд на микросервисную архитектуру озвучил сегодня Марк Ричардс в своем архитектурном понедельнике 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 :-) В ближайшие дни хочу сделать продолжение, которое начну с того чем закончил, т.е. с разговора о том Какие бывают архитектуры предприятия

19:00 MSK, в среду, 12 июля
Дилемма корпоративного архитектора 2.0
Продолжение разговора о том, чем должен заниматься архитектор предприятия в современной организации и есть ли что-то в его арсенале кроме тяжеловесных методологий описания текущего и целевого состояния ИТ-ландшафта

Регистрация здесь: https://mxsmirnov.timepad.ru/event/2495350/

Для интересующихся: краткая(очень) история и структура Enhanced Telecom Operations Map (eTOM). От динозавтров до наших дней, но без особого занудства. https://modelitics.wordpress.com/2017/04/27/introduction-to-etom/2/

Отчет о состоянии DevOps в России 2023 - полная версия

Команда Экспресс 42 при поддержке партнеров выпустила полную версию масштабного исследования состояния DevOps в России 2023.

В отчете - детальная статистика о состоянии метрик, практик и инструментов, результаты и планы компаний, неочевидные тренды на ИТ-рынке и конечно новые инсайты!

Full-версия исследования доступна для скачивания 👉 по ссылке

Трансляция начнется через 15 минут https://youtube.com/live/VaE0U4Lkut0

Ссылка на выступление Gregor Hohpe https://youtu.be/mS0AJLqmnvQ

Книжку привезли, почитаем 🧐

Мне всегда не хватало терпения для того, чтоб написать подобный текст или хотя бы слайд, да еще и с примерами (обычно я рассказываю что-то подобное просто размахивая руками). Но, наконец, я нашел заметку Inheritance and polymorphism: where the cracks in SQL begin to show, которую написал James Whiteside и слайд теперь обязательно нарисую.

Затрудняюсь сказать насколько хороши TypeDB и TypeQL, т.к. услышал о них впервые, но оказывается TypeDB уже была отмечена на недавнем техрадаре. В общем, надо бы присмотреться

Какая-то туманная история Decentralizing the Practice of Architecture at Xapo Bank появилась в bliki Мартина Фаулера. История о том как в банке, который начинал с работы с биткоинами, а не как банк... Так вот, в этом банке под консалтинговым руководством Thoughtworks организовали архитектурный комитет и стали обсуждать на нем ADRs (а корпоративных архитекторов вроде как выгнали, но это не точно).

А затеяла это всё ex-CTO этого банка. И теперь в банке другой CTO.

В общем, хочется сказать: вы там давайте поаккуратней экспериментируйте с практиками архитектуры предприятия. Ведь CTO можно и просто так поменять

Теория когнитивной нагрузки и архитектура предприятия

Теория когнитивной нагрузки Джона Свеллера, популяризированная в мире ИТ книжкой про командные топологии, не только и не столько о том, как правильно выстроить обучение и не перегрузить людей избыточной информацией.

Рассуждения о том, что способствует обучению, а что мешает, безусловно, важны, но в основе теории когнитивной нагрузки лежит некоторая (путь и крайне простая) модель устройства человеческой памяти.

Нельзя ли использовать эту модель и для описания деятельности целой организации? Ответ на этот вопрос, на мой взгляд, должен дать архитектор предприятия читать дальшe

Думаю, сообщения в разных блогах с заголовком типа Graphic Design for Software Engineers and Architects были актуальны и 5, и 10 и 20 лет назад и, безусловно, будут актуальны в будущем. Такие тексты будут появляться всегда, а я буду продолжать ими делиться. И может быть с частью вещей из этого текста я не вполне согласен, но согласен с главным: взялись рисовать картинку, так сделайте её нормально