Нашел чек-лист для проверки опровержения CAP теоремы. Если вы считаете, что сумели придумать решение, сочетающее в себе доступность, согласованность и устойчивость к разделению (consistency-availability-partition tolerance), то загляните сюда https://ferd.ca/beating-the-cap-theorem-checklist.html

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

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

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

Часто в таких случаях раздражение выплескивается на архитектора. Он же ведь эти диаграммы рисовал, а ведь мог бы вместо того пойти код писать. Только архитектор во всём это не виноват, ведь правда?

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

Месяцем позже Derek Comartin высказался на эту же тему в своем тексте/видео Google Service Weaver is a Bad idea Естественно сделав это несравнимо более полно и профессионально, чем я

С некоторых пор отмечаю в себе нездоровый интерес к кратким описаниям TOGAF. И вот еще одно: A Practical Guide to TOGAF Implementation от Visual Paradigm.

Описание представлено в двенадцати лаконичных разделах и сопровождается историей о том, что в какой версии появилось. Ну разве оно не замечательно? Думаю, чуть подсократить и на страницу бы поместилось

А вот здесь уже опубликовали видео моего недавнего выступления:
⏯ Job crafting в работе ИТ-архитектора

Готовился я тут к выступлению о том, как рассказывать архитектурные решения и набрел на короткую заметку Джорджа Фэрбенкса из 2011 года про архитектурные хайку Haiku tutorial (слайды внутри)

Продолжаю рассказывать про архитектурные репозитории - один из главных инструментов архитектора предприятия. В исходном сообщении я поделился ссылкой на HTML-представление учебного примера архитектуры предприятия ArchiSurance Case Study. Опубликовано оно среди материалов для архитекторов на сайте The Open Group, а непосредственно модель была изначально сделана в Archi.

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

SHOW TABLES 

ну а элементы модели получить SELECT-ами по соответствующим таблицам.

Подробней обо всем этом в первомайском тексте Xiaoqi Zhao: https://yasenstar.github.io/EA/architool/Query-Archi-HTML-Report.html