Раз уж я переименовал этот канал в "Архитектура ИТ-решений", то позволю себе иногда публиковать некоторые определения. Сегодня термин solution (решение) из руководства бизнес-аналитиков BABOK Guide v3
Solution:

A specific way of satisfying one or more needs in a context.

A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity

Давайте продолжим с определениями:
Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT supports that operation.

Note: A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks
[ TOGAF 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_69 ]

А вот вам состав описания архитектуры решения из прошлогодней книжки
Alan McSweeney, Introduction to Solution Architecture

Собрал в один плейлист вебинары, проведенные на канале IT Expert https://www.youtube.com/playlist?list=PLDwZgqHLFBe5B4Dt3dFszxo-p3xMalN8e

#youtube

Я всё ждал, а не перерисует ли кто-нибудь знаменитую картинку Джона Захмана 1987 года в приемлемом разрешении

Вдогонку. Фрагмент видео https://youtu.be/oUhOPcHginY
#youtube

The OpenAPI Specification (OAS) - стандарт описания REST API в виде YAML-файла.

Но YAML можно использовать и для описания микросервисов в Microservice Design Canvas. Прототип такого решения см. https://solusoftsl.github.io/microservices-design-canvas-editor/

Нашел свой довольно старый текст https://mxsmirnov.com/2014/03/20/why-ea/ и подумал, что вместо него следовало бы создать для архитекторов предприятия страничку ответов на часто задаваемые руководителями и заказчиками вопросы. Может кто видел такую штуку именно для EA?

Очень простое объяснение одного из паттернов микросервисной архитектуры https://medium.com/@volodymyrfrolov/pluggable-microservices-734457c3a3b3 Я уже говорил, что микросервисы бывают разными и изложенная в статье архитектура - лишь одна из нескольких. Но, задумываясь о микросервисах, я бы в первую очередь думал о "распределенных плагинах"

Вау! Оказывается Cloud native computing foundation с июня 2020 делает тематические технологические радары, наподобие ThoughtWorks. Сегодня появился уже второй https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/

Подробнее: https://radar.cncf.io/

В CQRS Documents by Greg Young https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf я всегда проскакивал мимо идеи о том, что анемичная модель предметной области, во-первых, это своеобразный способ обеспечения гибкости: когда ИТ-системы предоставляют россыпь объектов, которые можно как угодно модифицировать, а рабочий процесс реализован в головах пользователей и его изменение не требует доработок софта. А во-вторых - показатель бедности (Возникающие в таких системах ошибки, видимо, не столь критичны; как тактично говорит автор, эти системы имеют низкую ценность с точки зрения бизнеса)

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

В отличии от историков, архитекторы предприятия часто перерисовывают модели будущего. Есть даже традиция разработки нескольких целевых архитектур: для горизонта планирования год, три года и совсем отдаленного будущего, например. Для структурирования унаследованных приложений и данных было бы полезным наличие нескольких горизонтов прошлого. Например, до некоторого момента времени организация структурирует своих клиентов в соответствии с предоставленными им услугами. Затем, когда услуг становится слишком много, появляется понятие кампании – ограниченного по времени предложения пакета услуг, перевязанного праздничной ленточкой. Потом приходит пора когортного анализа, целевых предложений и других подобных вещей… Всё это разные представления клиентов, разные сценарии услуг, а часто и разные информационные системы. Обобщить это в единую концептуальную модель практически нереально.

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

Разбор AWS-овских картинок от Ilograph https://blog.ilograph.com/posts/fixing-aws-architecture-diagrams-vod/ Конечно, это в первую очередь реклама собственного инструмента, но придирки к картинкам Амазона и предложения по их улучшению вполне обоснованные

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

А заметки, опубликованные здесь, можно обсудить в специальной группе этого канала

June 2020, Philippe Kruchten:
30 years of software architecture https://youtu.be/70kyGrjs8rU
Слайды здесь: https://pkruchten.files.wordpress.com/2020/06/kruchten-2020-northrop-award.pdf

20 Октября Нил Форд будет хостить воркшоп по архитектурным катам. Если есть желание можно организовать команду и поучаствовать 🙂
https://learning.oreilly.com/live-training/courses/architectural-katas/0636920458463/

Все кто хочет поучаствовать - добавляйтесь в группу
https://t.me/joinchat/CSEd5Rvy_6VeCyuZlnkGpA

Иногда небольшая доля занудства помогает разложить всё по полочкам https://www.infoq.com/articles/event-driven-finding-seams/

Недавнее от Jeanne Ross: https://sloanreview.mit.edu/article/why-you-yes-you-need-enterprise-architecture/

Следует ли расценивать появление в iOS 14 такой штуки как App Clips (в русской версии блиц-приложения) как дальнейшее проникновении идей Грега Янга о Task based UI и CQRS?