Хотел запустить еще один опрос, но удержался. На этот раз тема несостоявшегося опроса следующая. Насколько оправдано стремление ИТ-архитектора донести до начальников и заказчиков те или иные технические знания? Всё больше склоняюсь к тому, что этого не нужно. Не надо рассказывать про всякие CQRS-ы, агрегаты и EventStore-ы. Проще надо быть, директивнее выражатьcя: хочешь, чтоб система не тупила, делай как я сказал дорогой заказчик!

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

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

Десять лет Architecture Decision Record (ADR). Оригинальный пост https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions от Michael Nygard

У авторов Team Topologies есть довольно большой текст о когнитивной нагрузке команд https://itrevolution.com/team-cognitive-load-team-topologies/ (а сам термин второе полугодие присутствует в технологическом радаре https://www.thoughtworks.com/radar/techniques/team-cognitive-load). Интересно, что до этого работы Джона Свеллера о Cognitive Architecture and Instructional Design вспоминали только в связи с обучением.

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

Есть один текст из блога The Open Group, перевод которого у меня почему-то никак не складывался. Но, наконец, всё встало на свои места. Евгений Погребняк доработал перевод истории про два типа архитекторов предприятия https://mxsmirnov.com/2021/11/18/archi123/ За что я просто не могу не выразить ему свою самую глубокую благодарность! Если в тексте вы, всё же, обнаружите какие-либо неточности - обязательно пишите

🤷🏻Наткнулся в ленте на эту заметку: https://cechinel.medium.com/system-design-c4-model-766683fed1c9 с правильными цитатами из c4model.com и крайне странной картинкой (см. выше).

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

Тоже поделюсь сегодняшним текстом с хабра про интервью аналитика https://habr.com/ru/post/591057/ С одной стороны хорошо, что аналитики наконец выучили слова идемпотентный или безопасный. С другой стороны, экономить на архитекторах всё равно себе дороже будет

Два года назад написал у себя в блоге заметку Развилки архитектурных решений с предостережениями для других. Сейчас пригодилось в качестве предостережения для самого себя, что подтвердило два банальных тезиса: 1) блог полезно писать; 2) еще более полезно его потом самому и читать

The Process Automation Map Любителям бизнес-процессов: большой текст про разные типы процессов (и подходы к их автоматизации) от Bernd Rücker (Camunda) https://blog.bernd-ruecker.com/exploring-the-process-automation-map-7d9aa181a747 и его более короткая версия https://techspective.net/2021/11/22/the-process-automation-map/

В целом, скептически отношусь к айтишным подкастам, но этот выпуск Читаем вместе https://t.me/readingtogetherdev/37 хорошо зашел. Спасибо! (... и это не реклама ;-)

Поделитесь своим мнением о моём сентябрьском тексте https://mxsmirnov.com/uml-schrodinger/ Я постарался вытащить несколько альтернативных суждений о том, что же с нами случилось четверть века назад от таких известных людей как Эрик Эванс или Алистер Коберн. Может надо было голосом этот текст записать? В общем, делитесь, и не только лайками, но и критическими замечаниями или вопросами. Спасибо!

Спасибо всем за поступившие комментарии! Жду продолжения, но выскажусь немного про Low-Code:

Просто идея. Может это и бред, но... В общем, сначала были венчурные инвесторы и был SaaS. Первые давали деньги вторым, а те передавали их AWS. Все хорошо работало! Потом SaaS стало много, впрочем, как и венчурных инвесторов и их денег. И еще AWS стало много, а вот пользователей, готовых платить за SaaS - не очень много. Подписку на доски купили, рисовалки купили, что еще юзеру надо? К несчастью в некоторый момент все научились деньги считать(end2end аналитика, юнит-экономика - все дела). В общем, нельзя стало делать SaaS без платящих пользователей. И тут разработчики SaaS задумались: чем бы еще юзверей развлечь? Покопались в архивах истории. Нашли! Тот самый low-code из начала этого затянувшегося сообщения.

Как говорится, чем бы дитя ни тешилось, лишь бы платную подписку продлевало!

Управленческий паралич. До пятницы еще далеко, но банальностей в ленте новостей уже хватает. Внесу и я свой скромный вклад в этот набирающий силу поток.

Я уже не раз вспоминал метафору Грегори Хоупа, сравнивающую архитектурное решение с финансовым опционом - возможностью, но не обязательством купить или продать в будущем некоторую бумагу по заранее зафиксированной цене https://architectelevator.com/architecture/architecture-options/ Кажется, что отправляя в будущее такие развилки архитектура препятствует своевременному принятию каких-либо решений. В частности, решений управленческих.

Но посмотрите на это с другой стороны. Корпорации скованны повальным нежеланием принятия каких-либо решений. Вопросы не двигаются с мертвой точки месяцами. Все как будто договорились исключить из делового лексикона слова "да" и "нет".

Хоть как-то изменить ситуацию могут гарантии возможности отказа от ранее принятого решения, возврата в текущее состояния. Те самые архитектурные "опционы". Они как тормоза, помогающие гоночному болиду ехать быстрее. Единственное, что архитектору предприятия неустанно надо об этом рассказывать

И снова в нашей группе архитектурные katas. Крайне престижное 2-место и отличный пример архитектурного описания. Но, в первую очередь, хочу обратить внимание на отличную презентацию постановки задачи и предлагаемой архитектуры ИТ-решения https://youtu.be/NENcmM48n-M

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

Всем привет!
Вчера моя команда заняла 2е место в конкурсе O’Reilly Arch Katas.
Так получилось, что в этом раз нужно было по-сути расширить функционал системы, которую спроектировал Андрей Гордиенко и победил на одном из предыдущих мероприятий.

Вот что получилось в итоге у нас: https://github.com/vadagama/sever_crew
Если по-делу накидаете на вентилятор, буду признателен. Хорошие отзывы тоже люблю. 🙂

Лет 10 назад я увлекался штукой, которая называется adaptive case management (в других источниках слово adaptive заменялось на dynamic или даже advanced). Этот термин обозначал особый вид бизнес-процессов, для которых не всегда можно указать правильную последовательность шагов, ведущую к цели, да и не так уж она важна по сравнению со спецификой данного конкретного случая. Здесь есть некоторая игра слов, даже смыслов. Слово кейс, с одной стороны, обозначает портфель или папку с бумагами (материалы дела, история болезни и т.п.), а с другой - некоторый уникальный прецедент, требующий своего подхода или решения (кейс, при обсуждении успешных примеров в бизнес-школе). Обычно с кейсом работает специально назначаемый на него человек – case worker (лечащий врач, адвокат, в общем knowledge worker), который и решает, что, когда и зачем следует делать в сложившейся ситуации.

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

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

Хорошей вам пятницы, друзья!

Мэтт МакЛарти представил большой текст про Data Mesh https://blogs.mulesoft.com/api-integration/api-management-and-data-mesh/ Возможно, после первых абзацев вы решите что читать его вряд ли следует, но не спешите. Автор вовсе не собирается безоговорочно поддерживать новую модную концепцию блистательной Жамак Дехгани. И потому дальше по тексту он выскажется о том, чем data mesh не является, а так же поделится своими мыслями и сомнениями. Почему-то, такое теперь редкость

Наконец расставил тайм-коды https://youtu.be/kN7XNp9Feio

Не только O'Reilly проводят архитектурные ката https://youtu.be/6MDKKuqn07A