А тем временем на Хабре появилось несколько переводов про 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/

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

Kubernetes Failure Stories https://k8s.af/

Второй день в чатике архитекторов https://t.me/itarchitect продолжается обсуждение очередной серебряной пули (кстати, открыл для себя несколько новых слов, например "АСУнизация")

Всё же не зря буржуи развивают культуру питчинга (... и здесь я должен бы в очередной раз порекламировать свой тренинг по архитектуре ИТ-решений, но воздержусь :)

… я сейчас глупость одну скажу в продолжение обсуждаемой темы: обреченность универсальных подходов, единых моделей и прочих странных вещей из это серии проистекает из-за сильного влияния на систему контекста (окружения, проблемной области…), в котором она эволюционирует. Внешние обстоятельства важнее внутренней структуры системы, т.к. именно они её формируют, под них она постоянно подстраивается. Потому мы и называем эту часть software. Эта мысль, в частности, противоречит фундаментальному подходу нобелевского лауреат Герберта Саймона (Herbert Simon), изложенному в цикле лекций Науки об искусственном (The Sciences of the Artificial), предложившему создать науки о рукотворных системах. Но для программных систем, похоже, мы остаемся в фрейме естественных наук, а задачей архитектора всё больше становится проектирование систем адаптивных, устойчивые к изменениям внешней среды чем, например, концептуально целостных

Огромное количество ссылок выдает гугл по слову Flexbox. Я решил остановиться на этой https://developer.mozilla.org/ru/docs/Learn/CSS/CSS_layout/Flexbox, которая представляется мне довольно понятной, хотя не самой красивой. А вспомнил я про CSS Flexible Box Layout из-за недавнего обсуждения требований к редактору архитектурных диаграмм.

Напомните мне, какой-либо из UML/Archimate/DFD/ERD/... редакторов, который помогает вам подобным образом визуализировать архитектурные диаграммы? (продукты от yWorks не вспоминаем; это отдельная история)

Распределенная сетка данных (Еще одна попытка для тех, кто раз пять уже не смог внедрить единое корпоративное хранилище данных)

Сегодня на InfoQ появилось краткое изложение Томасом Беттсом майской статьи Жамак Дехгани
https://www.infoq.com/news/2020/01/distributed-data-mesh/ , а заодно и анонс будущего подкаста. Исходная статья https://martinfowler.com/articles/data-monolith-to-mesh.html была довольно объемной, а трехминутный обзор прямолинеен лаконичен и прост

Немного про зарплаты архитекторов: https://www.thebalancecareers.com/top-paying-tech-careers-2071299

... Какая-то крупная компания создаёт интересный продукт, делает часть его функций открытой, но самую важную часть оставляет платной. Сообщество пользуется-пользуется, а потом кто-то махнёт рукой и сделает форк, реализовав в нём те самые платные фичи и открыв их для всех. Вот KeyDB — тот самый случай» https://habr.com/ru/company/flant/blog/478404/

А вообще, нормальный как-бы Redis - крайне актуальная тема

В тему инструментов отрисовки графов

Поделюсь еще одной странной картинкой о том, какими бывают ИТ-архитекторы 😜 (UPD: Картинка не моя, но названия строчек и столбцов заслуживают внимания)