Вместо упрощения подходов к описанию архитектур они усложняются

Новые сущности, появившиеся в прошлогодней версии стандарта ISO 42010, на рисунке, опубликованном на сайте рабочей группы

[1] Источник картинки
[2] Чуть подробней об изменениях в стандартах 420x0 в моем блоге

Сразу несколько текстов у Фаулера на модную нынче тему #PlatformEngineering
1. How platform teams get stuff done от бывшего эксперта из Thoughtworks Pete Hodgson-a и пара новых заметок в блики от Мартина:
2. TeamTopologies
3. TwoPizzaTeam

Где-то внутри ссылка на старый текст Эвана Ботчера What I Talk About When I Talk About Platforms

Из серии: советы архитектору решений (solution architect)

Кстати, вполне себе годный текст от Дэна Хьюза; по крайней мере, для пятницы 6 Tips for Beating Diagram Procrastination

Как корпоративному архитектору выжить в цифровом мире
Многие ИТ-директора в крупных организациях сделали поразительное открытие: в digital natives компаниях часто нет архитекторов, по крайней мере, обладателей формального титула Enterprise Architect...

Я не часто делюсь ссылками на тексты консультантов. Но конкретно этот мне кажется довольно полезным How enterprise architects need to evolve to survive in a digital world

Приближаемся ли мы к закату BPMN и поддерживающих его инструментов и началу нового этапа развития систем управления бизнес-процессами? https://www.infoq.com/news/2023/08/uber-cadence-workflow-platform/
Посмотрим!

Хозяйке на заметку Top 6 tools for text-based UML sequence diagrams

Обратите внимание: cтатья о причинах, по которым полезно задуматься о выделении функций и данных в отдельный сервис, включает набор дополнительных текстов по каждому из факторов https://tanzu.vmware.com/content/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind

История приложения мониторинга качества сервиса в Amazon Prime Video’s оказалась не столь однозначной. Сначала вроде бы утверждалось, что от микросервисов им пришлось отказаться так как такое решение не выдерживало и 10% требуемой нагрузки. С чем легко справлялся монолит. Вслед за таким сообщением появилось много радостных комментариев от тех, кто всегда настороженно относился к распределенным архитектурам и всяким там микросервисам

Но вот это видео Distributed isn't Microservices, In-Process isn't a Monolith знаменовало перелом в суждениях экспертов по поводу данного конкретного кейса (и, да, я подписался на CodeOpinion от Derek Comartin именно после этого ролика)

Более полный репортаж с места событий см. здесь Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All

Развилки архитектурных решений
Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку [читать дальше...]

Нашел вот такое исследование Difficulty of Architectural Decisions – A Survey with Professional Architects, в котором поучаствовало 43 архитектора и 86 архитектурных решений.

См. основные затруднения на картинке выше. В исследовании так же пытаются найти различия между решениями начинающих и опытных архитекторов, а еще: decisions with a more preferable outcome (i.e. good decisions) and decisions with a less preferable outcome (i.e. bad decisions)

Читаю TOGAF® Series Guide - Architecture Skills Framework и рассматриваю таблички с навыками разных архитекторов. Вот интересно, а кто всё это придумывает! Из каких вот соображений? Почему, например, у Solution Architect знания языков программирования должны быть выше, чем у архитекторов приложения и технических архитекторов, а готовые решения (COTS) ему надо знать в меньшем объеме (табличка из раздела 5.5 IT General Knowledge Skills)? И насколько все это согласуется, к примеру, с тем же SFIA Solution architecture?

Еще один пример Event Storming, Black Magic or Real?

14 сентября в 10:30 расскажу про свой новый учебный курс
Модели корпоративной архитектуры.
TOGAF 10 и Archimate 3.2

📎 Подробности и регистрация

Думаю, этот джин лениво выползает из своей бутылки. Сначала McKinsey утверждает, что Yes, you can measure software developer productivity. Потом Kent Beck начинает с ними спорить (см. часть 1, часть2), рассказывая как продавцы и рекрутеры обманывают свои KPIs и чем их труд отличается от разработки. В конечном счете все вокруг теперь обсуждают как измерять программистов

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

В общем, мир, в котором все программисты работают на 3-5 облачных PaaS за скромное вознаграждение, уже не выглядит такой уж абсолютной утопией

Добавил ответы на часть вопросов, касающихся Solution vs. Enterprise архитектуры https://youtu.be/cNRyS3qQXBc

Текст, конечно, старый, но всё еще актуальный https://medium.com/iasa-global/why-frameworks-are-killing-architecture-ebd758b5137e

https://www.tg-me.com/it_arch?boost

Проголосуйте за наш канал (для обладателей premium подписки. Если ссылка еще не видна, то она появится после обновления приложения)