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

Похоже, что запись устного рассказа на 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/ Будем отслеживать повнимательнее. Вдруг и правда что-нибудь из этого выйдет

Интересно, будет ли эта история иметь какое-либо продолжение?

В коротком сообщении о выходе сразу двух версий web-клиента мессенджера telegram, имеющих схожий набор функций, сказано: мы верим во внутреннюю конкуренцию.

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

Эту картинку я утащил из заметки Gregor Hohpe Thinking Like An Architect Part 2: Architects See More Dimensions и вспоминаю её всякий раз во время жарких дискуссий в соц.сетях.

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

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

А вот и обещанный подкаст с расшифровкой https://www.infoq.com/podcasts/architecture-design-trends-report/ Мне показалось, что участники разговора постоянно что-то упускают и сами это чувствуют. Будто забыл какое-то нужное слово. И сам его не можешь и собеседники не готовы подсказать. Впрочем, подкаст большой, надо еще раз будет к нему вернуться

Зацепившись взглядом за этот твит Gregor Hohpe https://twitter.com/ghohpe/status/1386808304987475972 я набрел на длинную, но интересную дискуссию с банальным заголовком Has UML died without anyone noticing? (см. здесь https://news.ycombinator.com/item?id=26934577 и здесь про используемые диаграммы: https://news.ycombinator.com/item?id=26940593)

Интересна она набором неочевидных гипотез относительно снижения популярности UML, например таких, как изменение модели поставки ПО или упоминаниями идей типа GML - Galactic Markup Language от Кента Бека :-)

Минутка графомании: для чего нужна ИТ-стратегия

Существует множество банальных ответов на этот вопрос: поддержать стратегию бизнеса, оптимизировать использование ресурсов, расширить, углубить и пр.

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

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

Вещь, которая выстроит динамическое равновесие между деньгами, людьми, изменениями, клиентами, партнерами и регуляторами называется… правильно, стратегия. А её воплощением в нашей материальной реальности занимается архитектура предприятия

Набросал анимированную картинку к рассуждениям выше
PS: обновил

Большая, быть может даже чуть-чуть занудная статья, в которой есть пожалуй все важные вещи для понимания распределенных систем. Статья с очевидными историческими параллелями о хранении данных на внешних запоминающих устройствах в старые добрые времена https://queue.acm.org/detail.cfm?id=3236388

Хочу вытащить из чата "Мастерская ИТ-тренера" тему про конструкторов (вероятно, наиболее близкий английский термин design engineer). Может и правда solution architect в большей степени именно конструктор, воплощающий новые продукты и фичи из имеющихся ресурсов и возможностей организации. Как вы думаете?

Мне кажется, нужно вообще забыть слово «архитектор» применительно к решениям (продуктам)

Над решением работает команда конструкторов. Конструкторы ПО (как мин бэк и фронт), конструктор инфраструктуры, конструктор ИБ

Руководит этой командой Главный конструктор - архитектор решений