Порочные круги в практике архитектуры предприятия от Святослава Котусева https://www.bcs.org/content-hub/vicious-and-virtuous-circles-in-enterprise-architecture-practice

Закат интеграции приложений. Надо бы мне текст написать. Или даже доклад на какую-нибудь конференцию подготовить. Но конференций много, а мыслей в голове мало. Потому сделаю текст и интерфейс к нему для доклада на конференции. Ну, а с конкретной реализацией конференции под этот интерфейс мы как-нибудь потом разберемся. Не найдем конференцию, сделаем вебинар.

Собственно говоря, речь о том, что вся история про интеграцию приложений, придуманная лет 15-20 назад или раньше, сегодня абсолютно неактуальна. Неактуальны все эти страшилки о вреде интеграции точка-точка и правильности использовании сервисной шины. Устарели наши привычки делиться справочниками, чтоб потом зашивать в данные идентификаторы непонятно чего, каталогизированного непонятно где. Ну а про бесконечный процесс синхронизации состояний образа одного и того же объекта, представленного в разных системах я уж вообще молчу.

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

А что мы получили взамен устаревших подходов? Похоже, не очень многое…
(продолжение следует)

Живое обсуждение предыдущего сообщения в комментариях и группе канала подсказывает, что делать мне надо не доклад на конференцию, а баттл. Что ж, я готов. Мои тезисы:
1. Большинство историй про интеграцию приложений было придумано довольно давно. Тогда мы еще не знали таких слов как CQRS, Event sourcing, DDD, не понимали разницы между stateless и stateful или разницы между запросом, командой и событием. Причем истории эти сочиняли ИТ-маркетологи, чрезмерно упрощая задачу интеграции, а часто теряя суть
2. Новых историй не появилось. Если в архитектуре ПО мы еще можем более-менее правдоподобно объяснить зачем мы делаем интерфейс, то в интеграционных задачах чего-то подобно я не слышал. Если кто-то может рассказать, поделитесь
3. Корпоративные ИТ-ландшафты меняются. Приложения собираются в более крупные конструкции (плохой термин «платформы») с одной стороны, но внутри себя распадаются на сервисы. Данные становятся общими. Потоки взаимодействий можно делить на запросы, команды и события и обрабатывать их разными сервисами. Где в такой картине мира интеграция – не очень понятно. Да, процессы внутри системы взаимодействуют между собой, но это другая история
4. С ростом популярности облачных вычисления, куберов, service mesh и т.п. до нас стало доходить, что межпроцессное взаимодействие, на одном узле, пусть и по сетевому протоколу, и вызов сервиса, развернутого с другой стороны интернет, как говорится – две большие разницы.
В общем, можете продолжать называть в комментариях это бессмысленным популизмом, но тема для разговора, как мне кажется, во всем этом есть

Был у меня однодневный учебный курс Карта ИТ-ландшафта Проходил он нечасто, но довольно динамично, как и положено блицу. Переводить в онлайн-формат мы его в прошлом году не стали. Но похоже, сделать в онлайн-формате аналог следовало бы. Конечно, сохранив быстротечность (2 занятия + время на упражнение между ними) и акцент на практический результат. Нужно ли кому-нибудь из подписчиков карты ИТ-ландшафта порисовать?

Спасибо за ваши отклики! Курсу «Карта ИТ-ландшафта» в онлайн-формате быть. Вначале августа проведу открытый вебинар, а пока сделаю небольшой опрос по формату.

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

Не буду делать голосовалку. Просто попрошу поделиться номером предпочтительного варианта. Напиши в комментах 1 или 2 (можно предложить и другие варианты)

Смотрю свежую заметку в блоге Draw dependency graphs in diagrams.net И вот всё у них хорошо. И ациклические ориентированные графы (DAG) тема крайне актуальная и графы зависимостей много кому нужны. А еще импорт вершин и ребер из CSV никогда не будет лишним и mermaid syntax вещь вполне рабочая.

Вот только картинки не назовешь красивыми. Ну что тут будешь делать!

📆 22 июля 19:00 MSK
Вы не поверите, но у меня анонс еще одного вебинара. Через неделю в Высшей школе бизнес-информатики ВШЭ буду рассказывать про Платформу цифровых сервисов (в формате для менеджеров). Запись вряд ли будет, так что записывайтесь здесь: https://hsbi.hse.ru/events/seminars/vebinar-platforma-tsifrovykh-servisov/

Накануне мероприятия придет ссылка на зум

Погружение в унаследованный ИТ-ландшафт это примерно то же, что покупка нового ноутбука с предустановленным ПО. Куча иконок непонятно для чего и зачем, непрерывные обновления и назойливые предложения продления/покупки лицензий. И главное, что удалить особо ничего нельзя, потому что из-за этого обязательно где-нибудь что-то отвалится. Правда ноут можно полностью перезалить заново, а вот корпоративный ИТ-ландшафт…

Хватит в канале анонсов моих событий. Поделюсь приглашением выступить на ArchDays. Планирую сделать это сам и вам рекомендую

Ищем спикеров на ArchDays.ru

Мы взрослеем и в этом году расширяем скоуп тем, выходим за рамки микросервисной архитектуры.

По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.

Небольшой спойлер. Я уже писал, что платформу можно рассматривать как набор ограничений. Ограничений на структуры данных и сценарии взаимодействия, способы расширения и развития; а так же требование использования общих функций и сервисов. (Очевидная калька с архитектурных стилей Роя Филдинга или парадигм программирования Боба Мартина). Следования ограничениям должны обеспечиваться довольно четкими механизмами, но позволяют достичь ряда полезных свойств.

Надеюсь, получится поговорить о платформах с этого ракурса

Запущу еще один круг рассуждений на тему: платформа - ограничения или возможности. Возможности хороши тем, что предлагают нам альтернативные варианты развития событий. Мы пользуемся возможностью или игнорируем её. Предпочитаем одну возможность другой или какой-то третьей. Т.е. находимся в ситуацию, которую Gregor Hohpe сравнил здесь с продажей опционов. Но предпочтя некоторый вариант другим, мы утрачиваем возможность выбора. В этот момент возможность перестает существовать. Это хорошо для менеджера, задача которого устранять неопределенность, но плохо для архитектора. Ограничение же наоборот, сохраняет возможность последующего выбора.

Можно провести аналогию с понятием интерфейс. Неискушенный интегратор считает, что специфицирование интерфейсов помогает связывать системы между собой. Более опытный скорее скажет, что интерфейс ослабляет связность. Сохраняет возможность замены одной из сторон взаимодействия на нечто другое, если и когда возникнет такая необходимость

Коллеги, как и обещал, анонс вебина по доменно-ориентированному подходу к интеграции:
https://sysanschool.timepad.ru/event/1714986/

Буду рад обратной связи!

Напоминаю, мы с Максимом Смирновым договорились устроить "баттл" по интеграции на конференции ArchDays

Выкладываю слайды вчерашнего вебинара про Платформу цифровых сервисов и вторую обещанную ссылку, которой не поделился в ходе вебинара. Речь шла о [мета-]процессах (или функциях или операциях), названия четкого нет, но идея в двух словах следующая.

В ООП у нас есть наследование и полиморфизм. Для двух объектов, несколько различающихся структурой и/или поведением, мы можем описать два разных класса, имеющих общего предка. При моделировании бизнес-процессов чего-то подобного нет. Когда нам нужно расширить функциональность, мы меняем описание процесса (в крайнем случае вызываемого подпроцесса, но концепции «интерфейс-реализация» там тоже нет). В общем, бизнес-процессы архитектурить не очень удобно. Максимум что можно сделать – форкнуть процесс, но почему-то процессники и этого не делают.

В какой-то степени эту тему затронул Ивар Якобсон в Use-Case 2.0 <- вот обещанная ссылка

Поделюсь отличным обзором книжки Team Topology, который сделал Александр Поломодов. Типы команд и типы интеракций между ними будут еще десять раз меняться и уточняться. А вот тема ограничения когнитивной нагрузки вошла, надеюсь, надолго. Она очень такая архитектурная и потенциально может потеснить идею упрощения всего и вся, развить определенными практическими подходами теорию Джона Свеллера

До вебинара еще целая неделя, а регистраций на таймпаде уже больше 200. По традиции начну отвечать на некоторые вопросы, заданные при регистрации прямо сейчас. Пара похожих вопросов была о том, а что такое карта ИТ-ландшафта, кому и зачем она нужна.

Четкое определение ландшафтной карты появилось в языке описания архитектуры предприятия Archimate и просуществовало в тексте стандарта до версии 2.0 включительно. В те славные времена стандарт включал в себя 18 viewpoints, одним из которых и был Landscape Map Viewpoint. Каждая такая точка зрения формально описывалась в табличке и помечалась на шестиугольнике (см. картинку в следующей заметке).
Из более поздних версий стандарта описание этого и многих других точек зрения исчезло, но сохранилось в дополнительных материалах. См., например, ArchiSurance Case Study А если копнуть глубже, когда Archimate еще не принадлежал The Open Group, то можно найти и более интересные вещи, как например в работе Landscape Maps for Enterprise Architectures приводятся рассуждения об использовании этого подхода для визуализации произвольных ассоциаций между элементами двух множеств, задаваемых элементами еще одного множества. Впрочем, иногда карту приложений используют и как простую кластерную диаграмму или диаграмму взаимодействий. Я планирую на вебинаре успеть привести пять вариантов использования ландшафтной карты

Исходное позиционирование карты ИТ-ландшафта из Archimate 2.0

Нагло отрекламирую свой канал, но не просто так)
В посте ниже можнопосмотреть Landscape Map реальной компании)

Публикую так как:
- это абсолютно настоящая обезличенная Landscape Map
- компании уже не существует
- ее помогал мне делать Максим
- с помощью нее мы сделали проект по объединению трех компаний на одну

Внутри поста ссылка на Visio
https://tttttt.me/it_ace/270

Большой текст (на самом деле, кластер из нескольких текстов) о разрыве цикла модернизации унаследованных систем появляется на сайте у Мартина нашего Фаулера https://martinfowler.com/articles/patterns-legacy-displacement/

Тема модернизации корпоративных ИТ-ландшафтов, на мой взгляд, на сегодняшний день разработана достаточно хорошо. Интересно, смогут ли авторы добавить в эту историю что-то новое или ограничатся банальностями. Пока всё выглядит довольно скромно