Я думал, что под этим недавним твиттом Gregor Hohpe https://twitter.com/ghohpe/status/1441059739551420421 развернется флейм, но этого не случилось (Возможно, интересней хайповая переписка Буча с дядюшкой Бобом о том, являются ли микросервисы архитектурой или же стратегией развертывания https://twitter.com/Grady_Booch/status/1441871173957001224) Жаль, что не случилось. Тем трудней мне будет отстаивать тему заката интеграции приложений на archdays

Пока фейсбучек лежит можно полистать ютуб. И даже русскоязычные каналы про ИТ-архитектуру там обнаружить. Вот, например: https://www.youtube.com/user/Alellas/playlists

В группе началось обсуждение обновления профстандарта архитектора ПО https://t.me/itarchitect/98704. В принципе, такого рода стандарты вещь довольно безобидная. Ну, уровень квалификации у архитектора не выше 7-го. Еще какая-то загадочная вещь появилась с названием единая информационная среда.

В общем-то, ничего страшного, но на всякий случай лучше сразу уйти из под регулирования, переименовавшись, например, в архитектора ИТ-решений или еще в кого-либо

Курс по микросервисам[2] я сейчас провожу примерно каждые три недели. И каждый раз практические занятия по рисованию архитектур съедают часть и без того коротких 24 академ.часов. Похоже, единственный выход жестко фиксировать нотацию. В следующем потоке устрою эксперимент с нотацией от Мэтта Макларти[1], у которого синхронные взаимодействия обозначаются прямой стрелочкой, асинхронные волнистой, запросы помечаются стрелочкой со значком вопроса (?), команды маркируются символом (!) и т.д. И, безусловно, поделюсь результатами эксперимента

[1] A visual language for digital integration
[2] Курс Микросервисная архитектура

Песенка волшебника: https://youtu.be/E7M4SNzHMYQ (или сказочника?)

Нашел перевод статьи Ната Шутта Should that be a Microservice? Keep These Six Factors in Mind про 6 (на самом деле 6+2) причин задуматься о целесообразности реализации части приложения в виде микросервиса. Можно смотреть на этот текст, как на чек-лист такого выбора

Доброе утро! Я вам свое мнение на роадмап архитектора принес :) https://vvsevolodovich.dev/profession-solution-architect-roadmap/

Олаф Циммерманн (ZIO), автор шаблона архитектурных решений, известного как (WH)Y-statements, предложил пять критериев для Definition of Done архитектурного решения (см. рисунок)

Я бы трактовал их как: обоснование-альтернативы-подтверждение-документирование-план реализации и контроля. Впрочем, только названий недостаточно. Без устного обсуждения не обойтись https://ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html

Вдруг вам пока так и недовелось разобраться из чего состоит kubernetes. Тогда читайте перевод Внутреннее устройство Kubernetes-кластера простым языком из серии Kubernetes 101 (в серии пока 5 статей с большим количеством картинок, часть из которых даже анимированная; что-то банально, а что-то полезно)

Снова привязал к каналу группу для обсуждения. Посмотрим, что будет со спамом

За время отключения комментариев мне больше хотелось услышать ваши суждения вот об этом https://blogs.mulesoft.com/api-integration/strategy/a-visual-language-for-digital-integration/ Зачем оно нужно написал здесь: https://t.me/it_arch/1191

🛠150 проголосовавших на данный момент в опросе нашего чата Работа для ИТ-архитектора
- 69% (больше 100 человек) ищут понимания рынка труда ИТ-архитекторов, а еще 17% - других инстайтов
- всего 2% в поиске работы, 47% работают, но не исключают для себя других возможностей
- только 6% заглянули за новыми сотрудниками, 11% пришли пообщаться, а 5% не знают зачем пришли

Продолжаем опрос... 🔬

7 шагов для оценки архитектуры программного обеспечения при помощи Tiny Architectural Review Approach (TARA) с простым примером https://stefan-poeltl.medium.com/software-architecture-assessment-with-tara-e54844b78f73
1. Context Diagram and Requirements
2. Functional and deployment views
3. Code analysis
4. Requirements assessment
5. Identify and Report Findings
6. Create conclusions for the sponsor
7. Deliver the Findings and Recommendations

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

Раз в полгода thoughtworks выпускает очередной технологический радар. Эти обзоры были довольно разными: неожиданными и вполне предсказуемыми, спорными и банальными, задиристыми и скучными. Новый непохож ни на один из предыдущих. Чего только стоит:
В этом выпуске радара мы заметили гораздо меньше всплесков в разделе платформы... Наша гипотеза заключается в том, что по большей части организации выбрали поставщика облачных услуг (или двух) и стандартизировали Kubernetes и Kafka. И хотя основные облачные платформы продолжают выпускать новые сервисы, в них нет ничего особенного

Радар получился крайне осторожный (если не сказать настороженный). Минимальное заполнение раздела adopt по всем сегментам и практически пустой раздел hold; всё ушло в trial и assess https://www.thoughtworks.com/insights/blog/it-organizational-design/macro-trends-technology-industry-october-2021

Слайды Саймона Брауна с GOTO Copenhagen 2021 https://static.architectis.je/gotocph2021-diagrams-as-code-2.pdf (аж целых 97 штук) из которых я с удовольствием позаимствую выражение

notation independent  

(см. слайд 17: "The C4 model is
notation independent"). Ну и много прочих вещей, ставших актуальными за последнее время. Но то, что мы ставим модель превыше нотации и превыше инструмента - оч. круто!

А вот предложения по классификации интеграционных взаимодействий от Билгина Ибряма (Red Hat) https://www.infoq.com/articles/microservices-inside-out/

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

Давайте уж все веселые картинки по интеграции соберем https://microservice-api-patterns.org/ Microservice API Patterns (MAP) мне представляется наименее проработанной (картинок больше смыслов) историей, но такие обычно и завоёвывают популярность