Сравнение сервисных сеток и немного про альтернативы https://servicemesh.es/?utm_sq=g93pkk1sp2

Всё! Закрываем канал на праздники. Спасибо, что вы с нами! Встретимся в 2020-м
Поздравляю всех с наступающим Новым годом! Желаю счастья, успехов и весёлых новогодних каникул 🍾🎄🎉

Я написал статью о том, зачем нужна контекстная диаграмма, как её создавать и тестировать, как использовать: http://systems.education/context-diagram

Спасибо за комментарии Николаю Судникову, Денису Мишарину, Рафику Ямолееву и Максиму Смирнову

Новая книжка от Нила Форда и Марка Ричардса Основы архитектуры программного обеспечения (февраль 2020). Ознакомительный фрагмент на O'Reilly наводит меня на мысль о необходимости её почитать https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/

Netflix пообещал в 2020 году открыть исходники DBLog - собственного Change-Data-Capture (CDC) решения https://medium.com/netflix-techblog/dblog-a-generic-change-data-capture-framework-69351fb9099b

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

Если мне память не изменяет, то еще Джон Захман в своих ранних статьях говорил (и в матрице рисовал) о том, что необходимость логической модели возникает при декомпозиции решения на компоненты и команды(субконтракторов), возможно использующих разные технологии. Возникает из-за необходимости им между собой договориться. Грубо говоря: надо как-то формат файла отобразить на реляционную модель данных, вот вам и появляется логическая модель поверх двух физических, принципиально разных. Т.е. логическая модель - некоторый аналог интерфейса. Интерфейса, который скрывает реализацию. Кто её делает? Тот, кто, как минимум, владеет всеми задействованными технологиями. Может я путаю, и это не Захмана рассуждения, но мне они кажутся вполне разумными и обоснованными. А иначе зачем весь этот огород городить?

Ну, и моя история про матрицу Захмана здесь: https://mxsmirnov.com/2018/03/23/zachman/

Вот эта канва описания ограниченных контекстов в предметно ориентированном-проектировании (DDD bounded context) https://medium.com/nick-tune-tech-strategy-blog/bounded-context-canvas-v2-simplifications-and-additions-229ed35f825f чем-то похожа на шаблон описания микросервисов (см. выше https://t.me/it_arch/179) не так ли?

Вот оно оказывается как! После перехода от проектной организации работ к продуктовой, вдруг оказывается, что нужны программы. Новая статья на martinfowler.com: https://martinfowler.com/articles/programs-in-product-mode.html

Довольно неоднозначная, но полезная история https://www.codeproject.com/Articles/4043134/Message-Driven-Business-Process-Orchestration-usin Неоднозначная потому, что я бы повыкидывал бы половину БД на картинках (например на Figure 4. одна из стрелок точно лишняя, ну да ладно). Почему интересная: системы управления бизнес-процессами явный тормоз развития микросервисов: транзакции, состояния и т.п. О таких темах, как S-BPM, вроде бы, все уже давно забыли. Zeebe - чем-то принципиально новым не считаем, она о другом.

Но в тоже время в современных нам ИТ-архитектурах появилось столько всяких новых вещей. Например, а не пора ли включать в BPMN пиктограмму circuit breaker? Ну и вообще, что может быть более похожим на паттерн event sourcing, чем позиции из сетей Карла Петри. Сети Петри, вроде как для моделирования процессов придумали, разве нет?

В общем, митап пора делать о бизнес-процессах и микросервисах

Подарок архитектору предприятия от YouExec Бесплатный шаблон для Google slides или PowerPoint (и не говорите, уважаемые EA, что вы его не используете) из семи анимированных слайдов презентации бигбоссам стратегических карт https://youexec.com/strategy-maps-3e2djzvibo

Может быть нарочито просто, зато доступно про онтологии и графы знаний, с картинками и примерами: https://enterprise-knowledge.com/whats-the-difference-between-an-ontology-and-a-knowledge-graph/

Завтра в 10:30 MSK приглашен на запись очередного подкаста linkmeup Весь выпуск будет целиком посвящен ИТ-архитектуре https://linkmeup.ru/blog/528.html Слушать можно непосредственно в ходе записи или скачать позже. На то это и подкаст ;-)

А тем временем на Хабре появилось несколько переводов про REST. Первый: "REST API должен основываться на гипертексте" https://habr.com/ru/post/483528/ одного из сообщений Роя Филдинга в его блоге и нескольких комментариев к нему (Оригинал 2008 года: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

И еще один перевод https://habr.com/ru/post/483328/ вызвавший больше флейма, чем понимания

Если вы регистрировались на сегодняшний вебинар, но не получили ссылку на трансляцию, то вот она: https://youtu.be/tky1EiWRpNE

Начинаем в 11:00

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

Про вовлеченность аналитиков и архитекторов

Задачка по архитектуре предприятия (вымышленная): есть несколько систем, поддерживающих одну функцию. Например, CRM от мегавендора, развиваемый интегратором, самописный внутрикорпоративный сайт с данными о контактах с клиентами (интеракциях) и база знаний на готовом движке, развиваемая собственными силами. В компании идет рационализация портфеля приложений. Как правильно поступить: объединить три системы в одну, оставить как есть, объединить сайт с CRM, слить сайт и базу знаний, заменить всё новой коробкой.

Вопросы и уточнения в группе канала. Голосование ниже