Похоже, мне скоро придется перерисовывать пример с функциональной картой системы решения инцидентов https://mxsmirnov.files.wordpress.com/2016/04/inc.jpg Инноваторы service management считают, что привычная воронка поддержки, с выделением 1-го, 2-го и прочих уровней устаревает https://www.serviceinnovation.org/intelligent-swarming/ уступая место Intelligent Swarming. Ну, в общем-то, поддержка на практике сейчас где-то так и работает

С интересом обнаружил в гартнеровском отчете Magic Quadrant for Enterprise Architecture Tools, что в слоёной модели архитектуры предприятия произошла замена слоя application на solution. Собственно, я всё время в своих курса о solution architecture и рассказывал. Цитата:

Definition of Enterprise Architecture
EA is a discipline that proactively and holistically leads enterprise responses to disruptive forces. It does this by identifying and analyzing the execution of change toward the desired business vision and outcomes. Mainstream viewpoints of EA include:
Business architecture, which guides people, process and organizational change
Information architecture, which focuses on the consistent sharing of information across the enterprise
Solution architecture, which develops a direction for managing the portfolios of to-be solutions
Technical architecture, which focuses on evolving the technical infrastructure

Что-то подсказывает мне, что в IT4IT главная проблема заключена в слишком сложных картинках. Пара диграмм Эйлера и простая диаграмма классов - и принятие подхода пошло бы живее

Всё же, косноязычие ГОСТ Р 57100. Системная и программная инженерия. Описание архитектуры https://mxsmirnov.com/2017/06/10/gost-r-57100/ не главная его проблема(как впрочем и англоязычных предшественников).

Основной вариант использования описания архитектуры не в том, чтоб быть рабочим продуктом для обмена результатами, контроля и бла-бла-бла. Описание архитектуры в большей степени полуфабрикат, способный стать(или не стать) триггером обдумывания и обсуждения. Это явно следует из всего его содержания, всех этих разговоров про views, concerns и stakeholders.  Это интуитивно понятно, даже банально, но пока мы не вербализуем эту мысль, то не сможем и сформулировать практики обдумывания и улучшения ИТ-архитектуры

Немного странно, что, взвалив на себя две функции: отображение текущей архитектуры системы и проектирование её изменений, архитекторы, будто бы специально игнорируют третью – выявление случившихся изменений. Я как-то и не слышал, чтоб архитектор, а не кто-то другой, рассказывал бы про эволюцию приложения. Мол за последний год объем данных рос так, основная доля операций сместилась с этой ветки процесса на эту, количество расширений удвоилось; а еще случилось такое вот принципиальное изменение, поменявшее ключевые свойства, читай, архитектуру нашей системы. Не удивительно, что без учета такой динамики, погоня за целевой архитектурой напоминает историю про Ахиллеса и черепаху

Эта картинка из нового European Interoperability Framework (EIF), там еще есть и European Interoperability Reference Architecture, с картинками в Archimate и много чего еще

Обсуждение развернулось здесь: https://www.facebook.com/mxsmirnov.arch/posts/1686431914793949

Смотрите какой лонгрид нашел https://www.infoq.com/articles/crafting-architectural-diagrams

DDD и истории - простенький такой лэндинг: http://domainstorytelling.org/

И рисовалка к нему https://www.wps.de/modeler/ (исходники: https://github.com/WPS/domain-story-modeler)

В этом интервью куча крутых высказываний, например:
"Десижн мейкер должен тщательно продумать условия, при которых предмет должен работать. Должно ли здание выстоять при землетрясении? Как узнать, что оно уцелеет в землетрясении? Продумать всё это — работа лица, принимающего решения, а не статистика. Статистик просто проверяет соответствие заданным условиям."

"Беритесь только за те запросы, которые были тщательно продуманы. Побуждайте или даже заставляйте десижн мейкера профессионально расти" – где бы еще найти критерий и измеритель продуманности задачи.

Интересно сколько ложных выводов делается в мире каждую минуту людьми из-за неверной интерпретации результатов анализа данных? https://dev.by/news/cassie-kozyrkov

Все ведь уже знают про новый проект Алистера Коберна? https://heartofagile.com/

Из книжки FLOW(ну, помните,  Дональд Рейнертсен "Принципы...", в общем, с водопадом на обложке) на русском https://sdu2020.blogspot.com/2018/10/01.html

Придумал недобрый вопрос к продавцам архитектурных репозиториев, да и вообще всяких EATools: а у вас для элементов модели(architecture building blocks) предусмотрены метки, селекторы и аннотации как в kubernetes? https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Не обращал внимание на то, что в ITABoK v.3 от IASA есть кликабельная картинка https://iasaglobal.org/itabok3_0/

Зарплаты аналитиков (интернет опрос, август 2018) http://lib.spbcoa.ru/doku.php?id=salary_survey_2018

Любопытно https://insights.sei.cmu.edu/sei_blog/2016/03/three-roles-and-three-failure-patterns-of-software-architects.html О том, как трансформируется деятельность архитектора в ходе жизненного цикла системы и некоторых рисках  связанных с этим карьерных транзитов

Статья из серии #mustread самая короткая и одновременно содержательная история о том, что такое #DataGovernance и как об этой самой data governance правильно думать https://insights.sei.cmu.edu/sei_blog/2017/06/six-things-you-need-to-know-about-data-governance.html