Как-то раньше я и не задумывался о том, что подходы к развертыванию приложений можно взять и пересчитать 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 Явно у него талант методиста: подробно и слегка занудно, с очень простыми выводами, примерами и картинками. Прям завидую

Сегодняшние две вакансии в нашем чате Работа для ИТ-архитекторов https://t.me/itarchitect_jobs/11136 отлично показывают отсутствие у работодателей понимания чего следует ожидать от ИТ-архитектора и чего ожидать не следует. Наверное, проблема глубже, в подходе к управлению в целом. В двух диаметральных позициях. Приверженцы первой говорят, что у нас есть проблема X и мы хотим увидеть её технологическое решение. Приверженцы второй - предлагают использовать технологию Y. И им, в принципе, неважно какую именно пользу она принесет, пусть хоть какую-нибудь. Мало кого интересует поиск соответствия между множеством проблем и множеством потенциальных решений, аналога product-market fit

Это же относится и к поиску ИТ-архитекторов

Вот здесь The Application Rationalization PLAYBOOK красной нить проходит идея business value and technical fit, правда при анализе текущего ИТ-ландшафта в ходе рационализации портфеля приложений. Даже опросники есть (правда так себе, но их вполне можно довести до ума)

Похоже, что Simon Brown, придумавший для нас c4model, тоже стал немножко видеоблогером https://youtu.be/9LnYV2g7S-w Ну что ж, будем смотреть и слушать!

Забавный опрос, правда про США. Три сотни руководителей ИТ-служб (83% респондентов - компании среднего размера, от 500 до 5 000 сотрудников) спросили про cloud-native. 86% сказали, что именно туда они сейчас и движутся.
Однако только у 12% компаний на микросервисах базируется хотя бы четверть всех приложений

Не лучше обстоят дела с освоением kubernetes. А с API респонденты так вообще запутались, обозначив проблемы с мониторингом, обнаружением(service discovery), безопасностью, да и пониманием как используется тот или иной API https://www.volterra.io/resources/doc/Volterra_The_Rise_of_Cloud-Native_Apps_R1.pdf

*зловещим шепотом*: Двенадцатого, двенадцатого в двенадцать часов на сайте правительство появилось распоряжение №3277 от 9 декабря о начале инвентаризации информационных ресурсов и систем госорганов http://government.ru/news/41104/ (сразу вспоминается акт Клингера-Коэна 1996г.)

Что думаете, уважаемые архитекторы, об этой инициативе?

Шесть причин выделения микросервиса из монолита от Nate Schutta. (На самом деле причин 6+2, а при подготовки этой серии статей участвовал и Matt Stine)
1. Multiple Rates of Change
2. Independent Life Cycles
3. Independent Scalability
4. Failure Isolation
5. Simplify External Dependencies
6. The Freedom to Choose the Right Tech for the Job
- Multiple business owners
- Owned by multiple teams https://tanzu.vmware.com/content/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind

Я испытываю некоторую неловкость, когда просто делюсь в этом канале ссылками на статьи, а не собственными впечатлениями от их прочтения и обдумывания. Особенно, когда речь идет о таком авторе как Жамак Дехгани, подарившей нам термин Data Mesh. Но пока я буду собираться с мыслями может кто-то другой прочтет и прокомментирует. Высока вероятность, что получится уж точно не хуже, чем у меня. В общем, несмотря на наличие более ранних и довольно внятных статей про Data Mesh автор в начале декабря перерассказала заново и расширила эту тему https://martinfowler.com/articles/data-mesh-principles.html Наслаждайтесь!

2020 - разочарования и надежды на будущее. В канун Нового года можно писать про ИТ-архитектуру вещи, которые никому другому не интересны. Этот жанр называется итоги уходящего года и перспективы наступающего. Я сам этим иногда баловался, но сегодня я буду признателен тем, кто поделится в комментариях к этому сообщению своими размышлениями об ИТ-архитектуре в текущем моменте времени и, может быть, некоторыми прогнозами на будущее.

Где мы сейчас и куда идем?

В обсуждении этого сообщения было много сказано про контекст[ы] (читать, начиная отсюда: https://t.me/c/1304614627/8988)

Может пришло время дополнить всеми любимый закон Мелвина Конвея гипотезой двух структур. 1-ая обозначена Конвеем как структура коммуникацией организации, создающей систему. Она не определяет дизайн системы, а ограничивает его. 2-ая структура - множество контекстов. Наличие этих двух вещей, вернее их несоответствие друг другу и образую "тяни-толкай" эффект, потенциальный вечный двигатель непрекращающихся изменений и эволюции системы.

В принципе, в системной инженерии это практически сказано. Кроме, быть может, непосредственно самого тезиса, о том, что несоответствие структур enabling system и operational environment(s) и формируют целевую систему (system-of-interest)

🎄 --- Дорогие друзья!
Завершается год 2020. Мы всё ближе к Новому, 2021 году. 2021, как многие уже наверняка заметили, хоть и не простое число, но является произведением всего двух простых сомножителей 43 и 47. А значит, в Новом году нам есть на что надеяться

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

С Новым 2021 годом! 🍾🎄🎉

Термин Monolith, частенько используемый в качестве альтернативы микросервисов, выбран крайне неудачно. Его давно следовало бы заменить на термин Bottleneck. Причем речь идет как о разработке, так и об эксплуатации.

Представьте себе заголовки статей: выбираем между bottleneck-ом и микросервисами или почему мы решили вернуться назад к архитектуре bottleneck. По-моему, отлично звучит

Восемь новых видео с ArchDays 2020: https://www.youtube.com/channel/UC3d7WPEIIcnorj1ZTyxVa7w/videos