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

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

Вместо упрощения подходов к описанию архитектур они усложняются

Новые сущности, появившиеся в прошлогодней версии стандарта ISO 42010, на рисунке, опубликованном на сайте рабочей группы

[1] Источник картинки
[2] Чуть подробней об изменениях в стандартах 420x0 в моем блоге

Сразу несколько текстов у Фаулера на модную нынче тему #PlatformEngineering
1. How platform teams get stuff done от бывшего эксперта из Thoughtworks Pete Hodgson-a и пара новых заметок в блики от Мартина:
2. TeamTopologies
3. TwoPizzaTeam

Где-то внутри ссылка на старый текст Эвана Ботчера What I Talk About When I Talk About Platforms

Из серии: советы архитектору решений (solution architect)

Кстати, вполне себе годный текст от Дэна Хьюза; по крайней мере, для пятницы 6 Tips for Beating Diagram Procrastination

Как корпоративному архитектору выжить в цифровом мире
Многие ИТ-директора в крупных организациях сделали поразительное открытие: в digital natives компаниях часто нет архитекторов, по крайней мере, обладателей формального титула Enterprise Architect...

Я не часто делюсь ссылками на тексты консультантов. Но конкретно этот мне кажется довольно полезным How enterprise architects need to evolve to survive in a digital world

Приближаемся ли мы к закату BPMN и поддерживающих его инструментов и началу нового этапа развития систем управления бизнес-процессами? https://www.infoq.com/news/2023/08/uber-cadence-workflow-platform/
Посмотрим!

Хозяйке на заметку Top 6 tools for text-based UML sequence diagrams

Обратите внимание: cтатья о причинах, по которым полезно задуматься о выделении функций и данных в отдельный сервис, включает набор дополнительных текстов по каждому из факторов https://tanzu.vmware.com/content/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind

История приложения мониторинга качества сервиса в Amazon Prime Video’s оказалась не столь однозначной. Сначала вроде бы утверждалось, что от микросервисов им пришлось отказаться так как такое решение не выдерживало и 10% требуемой нагрузки. С чем легко справлялся монолит. Вслед за таким сообщением появилось много радостных комментариев от тех, кто всегда настороженно относился к распределенным архитектурам и всяким там микросервисам

Но вот это видео Distributed isn't Microservices, In-Process isn't a Monolith знаменовало перелом в суждениях экспертов по поводу данного конкретного кейса (и, да, я подписался на CodeOpinion от Derek Comartin именно после этого ролика)

Более полный репортаж с места событий см. здесь Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All

Развилки архитектурных решений
Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку [читать дальше...]

Нашел вот такое исследование Difficulty of Architectural Decisions – A Survey with Professional Architects, в котором поучаствовало 43 архитектора и 86 архитектурных решений.

См. основные затруднения на картинке выше. В исследовании так же пытаются найти различия между решениями начинающих и опытных архитекторов, а еще: decisions with a more preferable outcome (i.e. good decisions) and decisions with a less preferable outcome (i.e. bad decisions)

Читаю TOGAF® Series Guide - Architecture Skills Framework и рассматриваю таблички с навыками разных архитекторов. Вот интересно, а кто всё это придумывает! Из каких вот соображений? Почему, например, у Solution Architect знания языков программирования должны быть выше, чем у архитекторов приложения и технических архитекторов, а готовые решения (COTS) ему надо знать в меньшем объеме (табличка из раздела 5.5 IT General Knowledge Skills)? И насколько все это согласуется, к примеру, с тем же SFIA Solution architecture?

Еще один пример Event Storming, Black Magic or Real?

14 сентября в 10:30 расскажу про свой новый учебный курс
Модели корпоративной архитектуры.
TOGAF 10 и Archimate 3.2

📎 Подробности и регистрация

Думаю, этот джин лениво выползает из своей бутылки. Сначала McKinsey утверждает, что Yes, you can measure software developer productivity. Потом Kent Beck начинает с ними спорить (см. часть 1, часть2), рассказывая как продавцы и рекрутеры обманывают свои KPIs и чем их труд отличается от разработки. В конечном счете все вокруг теперь обсуждают как измерять программистов

А потом НЕинтернет-гиганты вынуждены будут оптимизировать свою разработку. Но если у FAANG есть глобальная воронка подбора и они могут моментально открыть найм новых разработчиков по всему миру, то обычные компании этого сделать не смогут. В них и так-то никто работать особо не хочет, тем более за среднеотраслевую зарплату, а тут еще McKinsey всякие шастают.

В общем, мир, в котором все программисты работают на 3-5 облачных PaaS за скромное вознаграждение, уже не выглядит такой уж абсолютной утопией