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

Пару дней назад в чате ИТ-архитекторов https://tttttt.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://tttttt.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, слить сайт и базу знаний, заменить всё новой коробкой.

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

Несколько моих соображений по кейсу:
1. Безусловно, всё определяется контекстом и нет каких-то общих рекомендаций по объединению/разделению приложений
2. Более того, будущее важнее настоящего (ну, если у нас ничего не рушится в текущий момент и не надо срочно тушить пожары). Т.е. куда мы пойдем зависит от ожиданий через год-полтора-два или десять.
3. Если сегодня цели противоречивы: служба работы с клиентами ожидает быстрых дешевых изменений, на которые не способен интегратор с текущей CRM коробкой; ИТ нацелено на контроль над complexity, в идеале не больше одной системы на бизнес-функцию и т.д., то это не значит, что так будет всегда. Т.е. надо садиться за стол, рисовать картинки и договариваться о будущем, пусть не очень близком, но обязательно светлом.
4. Но сначала глобальные тренды. Поддержка будет уходить в digital-каналы, людей заменять искусственные интеллекты, базу знаний вести и читать станут сами клиенты, нерадивых системных интеграторов постигнет agile, а часть их работы будут делать citizen developers со стороны заказчика. Да и вместо CRM-ов e у нас будут coreless, облачные customer experience платформы на микросервисах. Ответы на вопрос "когда?" – к вендору, интегратору и своим разработчикам
5. Но это всё случится не скоро, поэтому на пути к светлому будущему надо предложить среднесрочные варианты, позволяющие снять часть текущих противоречий. (Противоречивость требований – причина декомпозиции систем на части; верно и обратное - устранение противоречий упрощает ИТ-ландшафт)
6. Не все предложенные варианты взаимоисключающие. Можно рисовать этапы. Перед наступлением единой микросервисной (кто сказал микросервисной? Я не говорил) платформы будут промежуточные этапы. Например, отсутствующее в вариантах объединение самописного сайта и базы знаний или доработка текущего CRM силами внутренней команды и т.п. Так что обсуждение стратегического целевого состояния, с которым все согласны, мы заменяем на тактику прокладывания маршрута
7. Если мы не договорились по тактике, то как минимум надо договориться обвести одним кружком все системы (не люблю слово «платформа», но видимо назвать это надо так) и координировать все работы в рамках этой области

Большое спасибо всем откликнувшимся! Вопросы и комментарии приветствуются в группе канала

Скажите мне, что я сплю, и на самом деле Wardley Maps не имеют абсолютно никакого отношения к микросервисной архитектуре, т.е. соотносятся с технологиями примерно так же, как придуманные древними созвездия с реальным расположением звезд и мне не придется смотреть и анализировать вот это видео https://youtu.be/1cnLMuBABo0

Вот сейчас я проснусь и всё встанет на свои места. А звезды будут лишь точками на небе и между ними не будет никаких линий, как в планетарии

Domain Driven Design рекомендован многими авторами в качестве подхода распределения данных между [микро]сервисами. Но мне всё чаще приходится сталкиваться и с другими способами декомпозиции. Как говорится, не DDD единым разбивается монолит на микросервисы. В какой-то момент я начал коллекционировать такие способы. Ну, например, вы можете сделать декомпозицию, которую я называю шардирование по состоянию, храня в различных базах данных информацию об экземплярах бизнес-процессов, достигших некоторого состояния (на самом деле, удобнее хранить в одной базе экземпляры процесса, которые находятся "в шаге" от некоторого состояния; такая база размещается в перехватчике событий, переводящих процесс в это состояние) Много интересных идей можно найти, в ходе чтения книжки https://www.piter.com/product/raspredelennye-sistemy-patterny-proektirovaniya рекомендовал её и здесь в своем блоге https://mxsmirnov.com/2019/09/28/designing-distributed-systems/

А есть ли у вас примеры подобных паттернов (или антипаттернов)? Поделитесь, пожалуйста, в группе обсуждения этого канала