А вот эта картинка достойна отдельного консилиума с обсуждением методов излечения от UML

PS: Основная проблема этих документов не в том, что там что-то не так написано, а в том, что перед публикацией их никто не читал

Simon Brown с новой историей почему архитектурные диаграммы надо представлять как код (на придумываемом им языке описания архитектуры Structurizr DSL) https://dev.to/simonbrown/diagrams-as-code-20eo

ИТ-архитекторы люди разносторонние. Я раньше уже делился ссылкой на видео "Практика архитектурного проектирования ИТ решений" с YouTube-канала Евгения Никонорова - активного участника наших архитектурных обсуждений. С того времени у него появилось несколько роликов-размышлений и потому сегодня поделюсь ссылкой на сам канал https://www.youtube.com/channel/UC0fCSuasoxqJHoMSsZ-IHUg

А здесь у нас второй день проходит анонимный опрос о зарплатах ИТ-архитекторов: https://t.me/itarchitect/72733

Уже послезавтра вебинар по Open Agile Architecture. Добавил ссылку на регистрацию: https://us02web.zoom.us/meeting/register/tZYod-2urDIvGNQM8CzEBbYnkH5rdi_stasc

Если кто-то успел полистать стандарт https://pubs.opengroup.org/architecture/o-aa-standard и хочет в четверг поделиться своими впечатлениями - пишите в комментарии к этому сообщению; постараюсь вывести вас в эфир

Запись сегодняшнего вебинара здесь https://youtu.be/g9kmKXd_ukI

Слайды

Слайды Евгения со вчерашнего вебинара

Канал преодолел скромную отметку 4 тыс. Спасибо всем подписчикам за то, что вы с нами. Продолжайте делиться своими мнениями в комментариях, обсуждаете материалы канала в тематических группах, не стесняйтесь предлагать для публикации собственные материалы.

Оставайтесь с нами! ;-)

Я за визуализацию архитектурных моделей в виде диаграмм и не считаю обязательным использование каких-либо нотаций, особенно накладывающих ограничение на модель

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

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

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

Все сегодня делятся отчетом State of DevOps 2020 (кто-то, как DevOps Deflope ниже прямой ссылкой, другие - страничкой с регистрацией https://puppet.com/resources/report/2020-state-of-devops-report/) В отчете:
- High DevOps evolution correlates strongly with self-service capabilities
- A product mindset is key to scaling DevOps and your internal platforms
ну, и т.д.

Как-то раньше я и не задумывался о том, что подходы к развертыванию приложений можно взять и пересчитать https://thenewstack.io/deployment-strategies/ а еще и анимированными картинками сопроводить

Пока записи прошедшего в пятницу ArchDays 2020 еще не выложены, пересматриваю записи конференции 2019 года https://www.youtube.com/channel/UC3d7WPEIIcnorj1ZTyxVa7w

Рассматривая картинки в твиттере Жана-Батиста Сарроди думается мне, что open-source инструмент корпоративной архитектуры Archi всё дальше уходит от Archimate. В прошлом году Жан-Батист рассказывал как C4 Model рисовать, теперь вот про кастомные иконки и стереотипы рассказывает https://twitter.com/jbsarrodie/status/1331256064503853056

Хекслет сочинил большую статью про ИТ-архитекторов https://ru.hexlet.io/blog/posts/gid-po-professii-arhitektor

Диалекты архитектурных нотаций
Матрица Захмана, Archimate, UML, «4+1» говорят об одних и тех же вещах, похожими словами, за которыми подразумевают вещи довольно разные. Мы можем попробовать сопоставить эти понятия между собой, но это лишь сделает наглядным досадные несостыковки. Solution architect-у приходится выбирать с кем он. И часто ему лучше придумать свой набор понятий, дополнив перечисленные выше фреймворки следующими концепциями: containers из C4model, boundaries из диаграммы пригодности, Domain events и aggregates из Event Storming и может быть чем-то еще из диалекта конкретной организации

Заложники косвенной адресации (пятничное)

Множество архитектурных построений развернуты вокруг одной простой, даже можно сказать банальной идеи: в переменной можно хранить не только значение, но и ссылку на некоторую другую переменную. Ну, хорошо, не только на переменную, но и на функцию. Остальное, так или иначе выводится из этого примитива. Как изобрести кафку? Не извлекать сообщения из очереди, а скользить по ней указателем (см., например, вот этот несложный текст Kafka for Engineers). И так всегда и везде. Или нет?

Ну, как-то раз, в Domain Driven Design одумались, решили обозначить понятие value object, но потом снова взялись за старое :-)

Как-то мне всё больше и больше нравятся заметки Дэйва Таублера. Вот, например, ещё одна: https://medium.com/datadriveninvestor/are-aggregate-oriented-microservices-a-dead-end-6651db494f0e Явно у него талант методиста: подробно и слегка занудно, с очень простыми выводами, примерами и картинками. Прям завидую