Архитектура ИТ-решений
14.7K subscribers
298 photos
33 files
1.12K links
Номер заявления на регистрацию № 4782434961

Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Вебинары: https://disk.yandex.ru/d/0lwmomky8wCjgw
Download Telegram
Из серии "Лучше вместе" Чтобы проиллюстрировать синергию между стандартами TOGAF® и Open Agile Architecture вот такую картинку нарисовали в The Open Group

Напоминаю, что обсуждение происходит здесь: https://t.me/joinchat/RjhmcXf0go0zMjli
Наблюдая за нашим чатом "Работа для ИТ-архитекторов" я подумал, что надо бы набросать для архитекторов предприятия типологию ИТ-директоров. CIO он ведь тоже бывают разные и к каждому требуется свой подход. Есть директора-новаторы. Они внедряют какой-нибудь LeSS или SAFe участвуют в конкурсах на лучший проект (и побеждают, неожиданно, правда), пишут статьи и т.д. Такому только успевай патроны подносить. Есть CIO хозяйственники. Они строят дата-центры, торгуются по лицензиям, упорядочивают текучку разными модными методами, в общем – поддерживают порядок. С ними граничат директора-достигаторы: люди успешно завершающие проекты в срок, причем несмотря ни на что. Тем и другим нужны актуальные карты ИТ-ландшафта, обновляемые архитектурные репозитории и внятные рассказы о регулярном прогрессе. А еще есть создающие команды директора. Команда, вернее штаб, у такого директора сплоченная. Люди если и ругаются друг с другом, то при закрытых дверях, но никогда при заказчике. Архитектору в такой системе хорошо. Главное знать границы и помогать соратникам по штабу.

Наверняка есть и другие типы CIO. Хотите расширить типологию – пишите комментарии в группу
Архитектура ИТ-решений
Используете ли вы architecture decision record (ADR)?
Подправил картинку с результатами (цифры без нижнего варианта). Поддержка у ADR получается мощная: 30% используют, еще 22% собираются и 26% работают с архитектурными решениями, но в другой форме. Хотя доля скептиков, на самом деле, тоже большая. Для меня ADR – инструмент повышения качества архитектурной функции, в первую очередь. Ну и инструмент обучения, безусловно. Не смотрите на ADR как на следующую большую вещь в архитектуре. Наоборот, это скорее базовый навык – минимальный набор объяснений, который мы ожидаем от архитектора при ответе на наш вопрос
Архитектура ИТ-решений
Живое обсуждение сложилось вокруг темы платформы. Спасибо. У меня был очень простой набор соображений. 1) с технической точки зрения платформа изначальна должна содержать в себе механизмы расширений. Что это будет: история дяди Боба про инверсию зависимостей…
Продолжаем тему платформы. Я тут опять попался на разговор про платформы и в полемическом запале предложил рассматривать платформу как набор ограничений, накладываемых на решение. Если вы поняли на какого и какие ограничения вы накладываете, а главное зачем это делаете - то уж ладно, создавайте свою платформу. По-моему, что-то в этом есть, как вам?
А кому здесь новых фреймворков архитектуры предприятия? Вот такая вот штуковина с незатейливым названием Арчипег. Ценник у ребят просто аховый. Вряд ли кто подпишется. Зато метамодель более-менее внятно описана и даже UML-диаграмма классов нарисована https://www.archipeg.com/learn/archipeg-ea-framework-v1-metamodel
Текст написал. Можно было бы сопроводить его заголовком:
Почему нельзя просто так взять и спроектировать API https://mxsmirnov.com/2021/07/01/clean-architecture/

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

Собственно говоря, речь о том, что вся история про интеграцию приложений, придуманная лет 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 или в коментарии к этому сообщению.