Песенка волшебника: 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://tttttt.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) мне представляется наименее проработанной (картинок больше смыслов) историей, но такие обычно и завоёвывают популярность

Хотел запустить еще один опрос, но удержался. На этот раз тема несостоявшегося опроса следующая. Насколько оправдано стремление ИТ-архитектора донести до начальников и заказчиков те или иные технические знания? Всё больше склоняюсь к тому, что этого не нужно. Не надо рассказывать про всякие 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/ За что я просто не могу не выразить ему свою самую глубокую благодарность! Если в тексте вы, всё же, обнаружите какие-либо неточности - обязательно пишите