🤷🏻Наткнулся в ленте на эту заметку: 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://tttttt.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

В чем реальная причина отказа от проектирования решений? Почему команды не описывают архитектуру? Есть разные варианты ответа на этот вопрос: потому, что ленятся; из-за того, что не видят конкретной пользы; просто некому этим заниматься (и некогда)… На мой взгляд, все эти причины несколько поверхностны. Т.е. они имеют место быть, но под ними часто скрывается причина более весомая. Часто это озвучивается в доверительном разговоре как:
- Мы попробовали, но у нас как-то не пошло!

И вот здесь уже есть, о чем поговорить. А кто именно пробовал: разработчик, аналитик, devops-инженер? И что именно пошло не так. Всё ведь просто (на первый взгляд). Нарисовать контейнерную диаграмму из C4 может даже школьник. Ну вот, кто-то, допустим аналитик, нарисовал. У него все получилось. Разработчики кивнули, сказали: да, похоже на правду. И в следующий раз все ОК. Автор окрылен, испытывает легкую эйфорию и уже считает себя немного архитектором! Но потом наступает облом. Жесткая посадка! Диаграммы не рисуются, с решениями все спорят, вылезает масса технических деталей, на которые следует обратить внимание. А еще ограничения, мешающиеся сделать правильно. В общем, пригрезившиеся ожидания стремительного роста компетенций вас, как архитектора, серьезно расходятся с реальным положением дел. Вообще, это называется кривая Бандуры! (см. рис. в следующем сообщении. Про Альберта Бандуру надо отдельного поговорить. Его кривая встречается часто, но теория социального научения глубже и интересней кривой). Архитекторами становятся те, кто преодолевает барьеры. Но часто этого не случается.
Архитектуру не делают по банальной причине: потому, что не умеют! В это сложно поверить тем, кто регулярно создает архитектуры: – Чего там уметь? Проектируешь варианты, потом сравниваешь! Или тем, кто сам не делал, а только читал об этом: - в книжке же все понятно! Но в большинстве случаев уклонение от проектирования - простое желание не заниматься незнакомой работой.

Что с этим делать – на вебинаре, безусловно, поговорим https://tttttt.me/it_arch/1224

Кривая Бандуры

We have talked about Enteprise Architects and Solution Architects but did you know there are other types of Architects too? Here is a quick summary:

Talkitecht: Talks a lot about architecture but doesn't actually do anything useful.

Markitecht: Works for a software vendor. Their architecture slides are really marketing slides.

Barkitecht: Insists loudly that you must follow their recommendations but in reality has no power or authority. Their bark is worse than their bite. Alternatively - someone who does their best work on the back of a napkin at the pub.

Narkitecht: Spends all his time annoying project teams and complaining that nobody listens to him. (more common in the UK)

Snarkitecht: Writes posts like this (с) https://www.linkedin.com/posts/gideon-slifkin-a9813_we-have-talked-about-enteprise-architects-activity-6874258514122948608-qO-o

Всё же The Open Group - волшебная организация. В случайные моменты времени, очень не часто, кто-то там внутри просыпается и в блоге появляется какой-то текст. На этой раз про микросервисы от Avolution, который пилит решение Abacus
https://blog.opengroup.org/2021/11/23/how-to-use-microservices-a-guide-for-enterprise-architects%EF%BF%BC/ И посыл текста незатейлив: нельзя просто так распилить монолит на микросервисы. Нужно принять некую крайне сомнительную метамодель, установить KPIs и купить этот странный ABACUS, чтоб рисовать правильные дашборты миграции.

Вот за это, на мой взгляд, потом и не любят корпоративных архитекторов! Хотя, может я чего-то просто не догоняю

Полезное (в большей степени для аналитиков) https://link.medium.com/H6zVMfRJ6lb