Воронка инициатив. Я часто рассказываю о том, что наибольшую ценность архитектор ИТ-решений приносит не ответом на вопрос как? реализовать ту или иную задачу, а отвечая на вопрос что? делать в первую очередь, что во вторую, а что пока не делать вовсе... https://mxsmirnov.com/2021/04/01/i-funnel/

Малость тут есть: https://habr.com/ru/company/yota/blog/551566/

Теперь осталось понять какая из версий web-клиента Telegram лучше Version K или Version Z? https://bugs.telegram.org/c/4002

Давно хочу переписать набор непричесанных заметок из этого Telegram-канала https://mxsmirnov.com/2019/12/17/domain-map/ относительно моделирования агрегатов в Domain Driven Design, но все руки не доходят.

Как вы в предметно-ориентированном проектировании описываете агрегаты? Может есть что-то более детально проработанное, чем Event Storming и Domain Storytelling, а я просто отстал от жизни

Я и не подозревал о существовании такой штуки, как Руководство по стилю SQL от Саймона Холивелла https://www.sqlstyle.guide/ - странице, объединяющей различные рекомендации по именованию таблиц, столбцов, хранимых процедур, алиасов и оформлению SQL-запросов

Вы можете использовать эти рекомендаций, форкнуть их или создать свои собственные, - пишет автор - главное, чтобы вы выбрали стиль и придерживались его

Подниму сообщение из группы https://t.me/itarchitect

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

В общем, к осени я бы был готовым отвечать на такие вопросы

С начала апреля успел провести уже три очных трехдневных курса и в качестве задания в одном из них попросил слушателей записать короткие видеоролики или скринкасты с рассказом об архитектуре решения. Оказалось, круто!

Похоже, что запись устного рассказа на 3-5 минут, дополненную картинками, можно считать одним из форматов представления ИТ-архитектуры. Как думаете?

С интересом обнаружил эту историю в своем же блоге:

Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record) читать продолжение...

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

Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище.
К удивлению Семёна вечно занятый Евгений был на рабочем месте. Дорисовывая очередной слайд он бросил Семёну:
– Что у тебя?
– Доработка сервиса обработки заявок, — пробурчал Семён.
– И в чём вопрос? – поинтересовался Евгений.
– Оформляю архитектурные решения, хочу посоветоваться.

Евгений посмотрел эскиз, поморщился и выдал свой любимый вопрос:
– Альтернативы придумал?
– Дорабатываем существующий сервис – Семён слегка замешкался. – Или пишем новый.

В этот момент к разговору внезапно присоединились еще два участника. Проектный менеджер Пётр, курирующий все доработки внутренних приложений в рамках программы цифровизации административной и внтурихозяйственной деятельности и продуктовый менеджер Павел. Эти двое всегда ходили вместе и постоянно спорили между собой.
– Не надо нам ничего переписывать! – не здороваясь начал Пётр. – Всё должно было заработать уже вчера! Десятки заявок в день вручную приходится разгребать.
– Это потому, что Борис накосячил, – включился в разговор Павел. – Вручную разгребаются заявки, которые не обработались с первого раза.
– Ну вот и подвернулась возможность Борису реабилитироваться, — не сдавался Пётр.

Не дожидаясь, пока эти двое окончательно втянутся в бесконечный спор, Евгений встал, подошёл к доске и рисуя квадратики принялся увещевать участников импровизированного совещания:
– У нас несколько вариантов реализации этой задачки. Самый простой, но не самый правильный состоит в том, чтоб сделать ещё одну очередь и написать новый компонент, который будет перекладывать сообщения из старой очереди в новую. Попутно он будет трансформировать ваши заявки.
– Не вариант! – прервал Евгения Павел. – Половина заявок в этот момент уже лежит в очереди ошибочных сообщений и разгребать их будет не ваш волшебный сервис, а рота сотрудников службы поддержи.
Павел покосился на Петра, ища у него поддержки. Вопреки традиции постоянно спорить с Павлом Пётр закивал.
– Хорошо! Вариант номер два, — не отступал Евгений. – Подменяем существующий сервис новым, с таким же интерфейсом, что и сервиса Бориса. Он будет обрабатывать все заявки. Некоторые сразу сбрасывать в очередь, а часть отдавать в старый сервис.

Павел одобрительно закивал:
– Меньшую часть, я надеюсь, — удовлетворенно заметил Павел.
– Как получится, — включился в разговор Семён, про которого все уже, казалось, забыли. – Этот вариант не решит никаких проблем, только создаст новые!
Участники разговора повернулись к Семёну, стали разглядывать его с некоторой нехорошей настороженностью. Семён, уже с меньшей уверенностью, продолжал:
– Наша проблема в чём? Вот в этих синхронных вызовах внешних апи, — Семён указал рукой в правую часть доски, на которой могли бы быть нарисованы интерфейсы внешних систем, используемые для обогащения заявок дополнительными данными. – Сервис Бориса почему тормозит? Потому, что внешние системы ему медленно отвечают. Что новый сервис, что старый, работать всё будет так же плохо! Только дополнительный синхронный вызов воткнем, а по существу ничего не изменится.
Настороженность во взглядах собеседников стала преобразовываться в легкую злобу. Особенно у Евгения, предложившего, как ему казалось, такой отличный вариант.
– Ну и что с этим делать? – первым взял себя в руки Павел.
– Реплики данных из внешних систем, — предположил Семён
– И кто за это заплатит? – поинтересовался Пётр.
…
В общем, в этот день коллеги так ни о чем и не договорились. Евгений отправил Семёна писать adr. Семён быстренько накатал файлик с двумя вариантами: доработать существующий сервис или написать новый. А проблема осталась ждать своего решения

SFIA (The global skills and competency framework for a digital world ) - описание навыков архитектора решений (Solution architecture) https://sfia-online.org/ru/sfia-7/skills/solution-architecture

Да вы что! Неужели? https://www.infoq.com/articles/architecture-trends-2021/

А вот и долгожданная версия 2.8 Apache Kafka вместе с early access version of KIP-500, для развертывания кафки без ZooKeeper https://blogs.apache.org/kafka/entry/what-s-new-in-apache5

Поделюсь свежей историей с хабра о трудоустройстве одного из подписчиков канала на позицию solution architect https://habr.com/ru/post/553780/

И, кстати, как вы думаете, подобного рода истории надо выстраивать по схеме: экспозиция-завязка- развитие-кульминация-развязка или же их и так интересно читать? (интересуюсь для себя)

Дополню эту цитату ссылкой на книжку с говорящим названием The Enterprise As Story: the role of narrative in enterprise-architecture – February 27, 2012 by Tom Graves https://www.amazon.com/Enterprise-As-Story-narrative-enterprise-architecture/dp/1906681341

"Most current approaches to enterprise-architecture describe everything in terms of structure. Yet people work better with story than with structure – and people are the enterprise. As we expand the architecture towards a true whole-of-enterprise scope, we need to describe the enterprise as story. Story is everywhere in the architecture – even the enterprise itself is a story." (С) Tom Graves

Оказывается шведские товарищи уже не первый год работают над подрывом (disruption) традиционных практик архитектуры предприятия. Называется это The Milky Way Enterprise Map. Слайды и видео здесь: https://annikaklyver.wordpress.com/2020/01/04/presentations-of-milky-ways/ Будем отслеживать повнимательнее. Вдруг и правда что-нибудь из этого выйдет