Архитектура ИТ-решений
Скоро начинаем. Ссылка на трансляцию https://youtu.be/kN7XNp9Feio
SysopsSquad.pdf
2 MB
Забыл поделиться слайдами
Выложил интервью с Андреем Гордиенковым, победителем Architectural Kata by O'Reilly Oct-Dec 2020 https://youtu.be/5lxS2Kpc26Q
YouTube
Architectural Kata by O'Reilly - интервью с Андреем Гордиенковым
Интервью с Андреем Гордиенковым, победителем Architectural Kata by O'Reilly Oct-Dec 2020Разбор другого здания Architectural Kata by O'Reilly, April - May 202...
Из серии "Лучше вместе" Чтобы проиллюстрировать синергию между стандартами TOGAF® и Open Agile Architecture™ вот такую картинку нарисовали в The Open Group
Напоминаю, что обсуждение происходит здесь: https://t.me/joinchat/RjhmcXf0go0zMjli
Напоминаю, что обсуждение происходит здесь: https://t.me/joinchat/RjhmcXf0go0zMjli
Наблюдая за нашим чатом "Работа для ИТ-архитекторов" я подумал, что надо бы набросать для архитекторов предприятия типологию ИТ-директоров. CIO он ведь тоже бывают разные и к каждому требуется свой подход. Есть директора-новаторы. Они внедряют какой-нибудь LeSS или SAFe участвуют в конкурсах на лучший проект (и побеждают, неожиданно, правда), пишут статьи и т.д. Такому только успевай патроны подносить. Есть CIO хозяйственники. Они строят дата-центры, торгуются по лицензиям, упорядочивают текучку разными модными методами, в общем – поддерживают порядок. С ними граничат директора-достигаторы: люди успешно завершающие проекты в срок, причем несмотря ни на что. Тем и другим нужны актуальные карты ИТ-ландшафта, обновляемые архитектурные репозитории и внятные рассказы о регулярном прогрессе. А еще есть создающие команды директора. Команда, вернее штаб, у такого директора сплоченная. Люди если и ругаются друг с другом, то при закрытых дверях, но никогда при заказчике. Архитектору в такой системе хорошо. Главное знать границы и помогать соратникам по штабу.
Наверняка есть и другие типы CIO. Хотите расширить типологию – пишите комментарии в группу
Наверняка есть и другие типы CIO. Хотите расширить типологию – пишите комментарии в группу
Telegram
Работа для ИТ-архитекторов
Группа только(!) для публикации резюме и вакансий ИТ-архитекторов. Другие сообщения могут быть удалены
Правила см. в закрепе
Правила см. в закрепе
Используете ли вы architecture decision record (ADR)?
Anonymous Poll
10%
Да, вполне успешно
4%
Да, но ожидания пока не оправдываются
11%
Формулируем арх.решения, но в другой форме
10%
Нет, но собираемся
3%
Пробовали. Не зашло
7%
Не пробовали и не собираемся
54%
Не голосую. Хочу узнать результаты
Архитектура ИТ-решений
Используете ли вы architecture decision record (ADR)?
Подправил картинку с результатами (цифры без нижнего варианта). Поддержка у ADR получается мощная: 30% используют, еще 22% собираются и 26% работают с архитектурными решениями, но в другой форме. Хотя доля скептиков, на самом деле, тоже большая. Для меня ADR – инструмент повышения качества архитектурной функции, в первую очередь. Ну и инструмент обучения, безусловно. Не смотрите на ADR как на следующую большую вещь в архитектуре. Наоборот, это скорее базовый навык – минимальный набор объяснений, который мы ожидаем от архитектора при ответе на наш вопрос
Архитектура ИТ-решений
Живое обсуждение сложилось вокруг темы платформы. Спасибо. У меня был очень простой набор соображений. 1) с технической точки зрения платформа изначальна должна содержать в себе механизмы расширений. Что это будет: история дяди Боба про инверсию зависимостей…
Продолжаем тему платформы. Я тут опять попался на разговор про платформы и в полемическом запале предложил рассматривать платформу как набор ограничений, накладываемых на решение. Если вы поняли на какого и какие ограничения вы накладываете, а главное зачем это делаете - то уж ладно, создавайте свою платформу. По-моему, что-то в этом есть, как вам?
А кому здесь новых фреймворков архитектуры предприятия? Вот такая вот штуковина с незатейливым названием Арчипег. Ценник у ребят просто аховый. Вряд ли кто подпишется. Зато метамодель более-менее внятно описана и даже UML-диаграмма классов нарисована https://www.archipeg.com/learn/archipeg-ea-framework-v1-metamodel
Archipeg
Archipeg EA Framework v1.0 Metamodel - Archipeg - Cloud-Based Digital Enterprise Architecture Software
Detailed description of Archipeg Enterprise Architecture framework metamodel, version 1.0
Текст написал. Можно было бы сопроводить его заголовком:
Почему нельзя просто так взять и спроектировать API https://mxsmirnov.com/2021/07/01/clean-architecture/
PS: Пишите если текст непонятный и нужно провести вебинар
Почему нельзя просто так взять и спроектировать API https://mxsmirnov.com/2021/07/01/clean-architecture/
PS: Пишите если текст непонятный и нужно провести вебинар
Смотрите какой обзор нашел. Мой курс в IT Expert тоже посчитали https://howtolearn.ru/online-kursy/arhitektor-po.html#ITexpert хотя он больше про Solution architecture, а для архитектора ПО полезнее "Микросервисная архитектура"
Портал об онлайн-образовании | Где и чему учиться в интернете, в России и за рубежом
15 лучших онлайн-курсов архитекторов ПО: платное и бесплатное обучение, цены, дипломы
Хорошие дистанционные курсы и школы для начинающих архитекторов ПО, где научат архитектурному анализу, моделированию UML, работе с приложениями, обеспечивать безопасность и другим навыкам.
Порочные круги в практике архитектуры предприятия от Святослава Котусева https://www.bcs.org/content-hub/vicious-and-virtuous-circles-in-enterprise-architecture-practice
www.bcs.org
Vicious and virtuous circles in enterprise architecture practice | BCS
The fate of enterprise architecture (EA) practices in many organisations historically has been bumpy and stormy, writes Svyatoslav Kotusev, Enterprise Architecture researcher.
Закат интеграции приложений. Надо бы мне текст написать. Или даже доклад на какую-нибудь конференцию подготовить. Но конференций много, а мыслей в голове мало. Потому сделаю текст и интерфейс к нему для доклада на конференции. Ну, а с конкретной реализацией конференции под этот интерфейс мы как-нибудь потом разберемся. Не найдем конференцию, сделаем вебинар.
Собственно говоря, речь о том, что вся история про интеграцию приложений, придуманная лет 15-20 назад или раньше, сегодня абсолютно неактуальна. Неактуальны все эти страшилки о вреде интеграции точка-точка и правильности использовании сервисной шины. Устарели наши привычки делиться справочниками, чтоб потом зашивать в данные идентификаторы непонятно чего, каталогизированного непонятно где. Ну а про бесконечный процесс синхронизации состояний образа одного и того же объекта, представленного в разных системах я уж вообще молчу.
Не то чтоб пропали задачи: связать одну систему с другой, взять отсюда и положить туда, инициировать команду или перехватить событие. Они остались. Их не стало меньше. Но думать о них теперь надо как-то иначе.
А что мы получили взамен устаревших подходов? Похоже, не очень многое…
(продолжение следует)
Собственно говоря, речь о том, что вся история про интеграцию приложений, придуманная лет 15-20 назад или раньше, сегодня абсолютно неактуальна. Неактуальны все эти страшилки о вреде интеграции точка-точка и правильности использовании сервисной шины. Устарели наши привычки делиться справочниками, чтоб потом зашивать в данные идентификаторы непонятно чего, каталогизированного непонятно где. Ну а про бесконечный процесс синхронизации состояний образа одного и того же объекта, представленного в разных системах я уж вообще молчу.
Не то чтоб пропали задачи: связать одну систему с другой, взять отсюда и положить туда, инициировать команду или перехватить событие. Они остались. Их не стало меньше. Но думать о них теперь надо как-то иначе.
А что мы получили взамен устаревших подходов? Похоже, не очень многое…
(продолжение следует)
Архитектура ИТ-решений
Закат интеграции приложений. Надо бы мне текст написать. Или даже доклад на какую-нибудь конференцию подготовить. Но конференций много, а мыслей в голове мало. Потому сделаю текст и интерфейс к нему для доклада на конференции. Ну, а с конкретной реализацией…
Живое обсуждение предыдущего сообщения в комментариях и группе канала подсказывает, что делать мне надо не доклад на конференцию, а баттл. Что ж, я готов. Мои тезисы:
1. Большинство историй про интеграцию приложений было придумано довольно давно. Тогда мы еще не знали таких слов как CQRS, Event sourcing, DDD, не понимали разницы между stateless и stateful или разницы между запросом, командой и событием. Причем истории эти сочиняли ИТ-маркетологи, чрезмерно упрощая задачу интеграции, а часто теряя суть
2. Новых историй не появилось. Если в архитектуре ПО мы еще можем более-менее правдоподобно объяснить зачем мы делаем интерфейс, то в интеграционных задачах чего-то подобно я не слышал. Если кто-то может рассказать, поделитесь
3. Корпоративные ИТ-ландшафты меняются. Приложения собираются в более крупные конструкции (плохой термин «платформы») с одной стороны, но внутри себя распадаются на сервисы. Данные становятся общими. Потоки взаимодействий можно делить на запросы, команды и события и обрабатывать их разными сервисами. Где в такой картине мира интеграция – не очень понятно. Да, процессы внутри системы взаимодействуют между собой, но это другая история
4. С ростом популярности облачных вычисления, куберов, service mesh и т.п. до нас стало доходить, что межпроцессное взаимодействие, на одном узле, пусть и по сетевому протоколу, и вызов сервиса, развернутого с другой стороны интернет, как говорится – две большие разницы.
В общем, можете продолжать называть в комментариях это бессмысленным популизмом, но тема для разговора, как мне кажется, во всем этом есть
1. Большинство историй про интеграцию приложений было придумано довольно давно. Тогда мы еще не знали таких слов как CQRS, Event sourcing, DDD, не понимали разницы между stateless и stateful или разницы между запросом, командой и событием. Причем истории эти сочиняли ИТ-маркетологи, чрезмерно упрощая задачу интеграции, а часто теряя суть
2. Новых историй не появилось. Если в архитектуре ПО мы еще можем более-менее правдоподобно объяснить зачем мы делаем интерфейс, то в интеграционных задачах чего-то подобно я не слышал. Если кто-то может рассказать, поделитесь
3. Корпоративные ИТ-ландшафты меняются. Приложения собираются в более крупные конструкции (плохой термин «платформы») с одной стороны, но внутри себя распадаются на сервисы. Данные становятся общими. Потоки взаимодействий можно делить на запросы, команды и события и обрабатывать их разными сервисами. Где в такой картине мира интеграция – не очень понятно. Да, процессы внутри системы взаимодействуют между собой, но это другая история
4. С ростом популярности облачных вычисления, куберов, service mesh и т.п. до нас стало доходить, что межпроцессное взаимодействие, на одном узле, пусть и по сетевому протоколу, и вызов сервиса, развернутого с другой стороны интернет, как говорится – две большие разницы.
В общем, можете продолжать называть в комментариях это бессмысленным популизмом, но тема для разговора, как мне кажется, во всем этом есть
Был у меня однодневный учебный курс Карта ИТ-ландшафта Проходил он нечасто, но довольно динамично, как и положено блицу. Переводить в онлайн-формат мы его в прошлом году не стали. Но похоже, сделать в онлайн-формате аналог следовало бы. Конечно, сохранив быстротечность (2 занятия + время на упражнение между ними) и акцент на практический результат. Нужно ли кому-нибудь из подписчиков карты ИТ-ландшафта порисовать?
Архитектура ИТ-решений
Был у меня однодневный учебный курс Карта ИТ-ландшафта Проходил он нечасто, но довольно динамично, как и положено блицу. Переводить в онлайн-формат мы его в прошлом году не стали. Но похоже, сделать в онлайн-формате аналог следовало бы. Конечно, сохранив…
Спасибо за ваши отклики! Курсу «Карта ИТ-ландшафта» в онлайн-формате быть. Вначале августа проведу открытый вебинар, а пока сделаю небольшой опрос по формату.
Есть две основные опции: простая и полезная. Простая включает в себя два дня занятий примерно по 5 часов и упражнения на вымышленных примерах в ходе этих занятий. Полезная: два вечера лекций, неделю самостоятельной работы с вашими реальными кейсам (можно в группе из нескольких человек) и индивидуальный разбор для каждой группы примерно по часу на задание. А потом мы все вместе соберемся на полтора часа обменяемся мнениями, представим свои задания (по желанию), поделимся находками и наблюдениями.
Не буду делать голосовалку. Просто попрошу поделиться номером предпочтительного варианта. Напиши в комментах 1 или 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/
Накануне мероприятия придет ссылка на зум
Вы не поверите, но у меня анонс еще одного вебинара. Через неделю в Высшей школе бизнес-информатики ВШЭ буду рассказывать про Платформу цифровых сервисов (в формате для менеджеров). Запись вряд ли будет, так что записывайтесь здесь: https://hsbi.hse.ru/events/seminars/vebinar-platforma-tsifrovykh-servisov/
Накануне мероприятия придет ссылка на зум
Погружение в унаследованный ИТ-ландшафт это примерно то же, что покупка нового ноутбука с предустановленным ПО. Куча иконок непонятно для чего и зачем, непрерывные обновления и назойливые предложения продления/покупки лицензий. И главное, что удалить особо ничего нельзя, потому что из-за этого обязательно где-нибудь что-то отвалится. Правда ноут можно полностью перезалить заново, а вот корпоративный ИТ-ландшафт…
Хватит в канале анонсов моих событий. Поделюсь приглашением выступить на ArchDays. Планирую сделать это сам и вам рекомендую
Forwarded from Микросервисы / распределенные системы
Ищем спикеров на ArchDays.ru
Мы взрослеем и в этом году расширяем скоуп тем, выходим за рамки микросервисной архитектуры.
По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.
Мы взрослеем и в этом году расширяем скоуп тем, выходим за рамки микросервисной архитектуры.
По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.