Похоже, что 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

Хочу напомнить, что кроме группы для обсуждения этого канала, у нас есть группа для обсуждения всех прочих вопросов, касающихся ИТ-архитектуры https://t.me/itarchitect В ней намного больше участников и разнообразней представлены разные точки зрения

В живом обсуждении этого сообщения, на мой взгляд, постоянно ускользала одна простая вещь. Сервис – это просто процесс; фоновый процесс, запущенный под управлением операционной системы и обрабатывающий передаваемые в него через REST API запросы. (Ну, или процесс, читающие запросы из очереди сообщений и обрабатывающий их). Даже в самом простом приложении нам потребуются десятки коллекций веб-ресурсов: пользователи, справочники, операции совершаемые и уже завершенные, задействованные в этих операциях вещи и многое другое. У каждого их этих ресурсов свой жизненный цикл, свои представления для разного типа запросов, более или менее сложный набор операций и уж наверняка разная скорость будущих изменений. Будь это статические веб-странички, то каждый элемент любой из коллекций лежал бы в отдельном файле. Четверть века назад CGI (common gateway interface) предусматривал свой исполняемый модуль для каждой коллекции ресурсов, ну да ладно

Сегодня же нас не особо коробит обрабатывать все запросы, не важно читаем ли мы данные GET-ом, создаем ресурсы POST-ом или заменяем PUT-ом, причем запросы для всех используемых приложением веб-ресурсов из десятков совершенно разных коллекций одним исполняемым модулем. Это и правда такая архитектура? Даже архитектурный стиль с гордым именем «монолит» :-) Да нет здесь никакой архитектуры и это обыкновенный bottleneck. Подарок, так сказать, службе эксплуатации и будущим поколениям разработчиков из нашего непростого настоящего

Нашел еще один текст про архитектора решений (solution architect) на русском https://merehead.com/ru/blog/solution-architect/

Специально для тех, кто считает BPMN более-менее свежим способом моделирования, напомню: в этом году мы будем отмечать столетие появления процессных диаграмм

В 1921 году Фрэнк и Лилиан Гилбрет выступили с презентацией на ежегодном собрании Американского общества инженеров-механиков. Она была озаглавлена «Диаграммы процессов: первые шаги в поисках наилучшего способа выполнения работы» Обратите внимание на условные обозначения на 8,9 и 11 страницах и разговоры про улучшение процессов https://thegilbreths.com/resources/Gilbreth-Process-Charts-1921.pdf  
Что-то очень знакомое, не так ли?

К итогам прошлого года: многопользовательский редактор простых архитектурных эскизов, который я еще не успел опробовать в качестве инструментов на дистанционным обучении ИТ-архитектуре https://blog.excalidraw.com/rethinking-virtual-whiteboard/

Плюс появившаяся в конце декабря библиотечка для архитекторов https://libraries.excalidraw.com/

https://kroki.io с версии 4.0 поддерживает Excalidraw. Я писал обзор этой утилитки. Кому интересно, пост на моем сайте https://www.golodiuk.com/news/it-architecture-diagrams-from-text/

Сегодня немного про стратегию. Стандарт O-AA™ возвращает нас к понимаю стратегии, сформулированному Портером.

Michael Porter recommends distinguishing operational effectiveness from strategy. Strategy is about developing sustainable differentiation based upon strategic positioning.

“Strategic positioning means performing different activities from rivals' or performing similar activities in different ways.” — Porter 1996
https://pubs.opengroup.org/architecture/o-aa-standard/#strategy

Для последующего выстраивания архитектуры данный подход крайне удобен. Если мы изначально договорились об отличиях нашей организации от конкурентов, то ответ на вопрос: как именно это использовать, не представляет труда.

Проблема в том, что организации формулируют свои стратегии прямо противоположным образом – методом copy-paste из разных авторитетных источников и стратегий своих конкурентов. Поэтому, определение дифференциаторов часто выпадает на долю корпоративных архитекторов

Всё более вероятным мне представляется развитие событий, при котором нотации моделирования будут вытеснены палитрами элементов архитектурного представления (view) и отношений между ними. Это уже сейчас происходит у облачных провайдеров, выпускающих наборы иконок и руководства по архитектурным диаграммам (см., например, https://cloud.google.com/icons). Их легко расширять, адаптировать под конкретные задачи, версионировать и т.д. Если в подобных наборах чего и не хватает, так это наличия у каждой иконки гиперссылки, на страницу с описанием визуализируемого понятия

Сложнее ситуация с описанием отношений. Вообще говоря, N-арные отношения описываются фреймами, а визуализируются в виде canvas (вот здесь http://masterfacilitator.com/canvas-collection/ полсотни примеров). Но пока они слишком громоздкие, а потому никто не рискует включать несколько фреймов в одну диаграмму. Но рано или поздно это произойдет

Поделюсь кратким обзором https://t.me/theworldisnoteasy/1208 вот этой статьи https://medium.com/@EthanZ/beyond-facebook-logic-help-us-map-alternative-social-media-889b874b7aee про альтернативны современным социальным сетям