18 мая, 17:00 MSK Продолжаем бесплатные вебинары из жизни ИТ-архитекторов. Описание на странице мероприятия https://mxsmirnov.timepad.ru/event/1639808/

На вебинар зарегистрировалось уже под сотню участников, но вот вопросов совсем мало. Их можно задавать не только при регистрации, но и на странице https://fb.me/e/2aVx3qI8S или в комментариях к этому сообщению.

Ответы на них будут в ходе вебинара, но на пару вопросов я начну отвечать прямо сейчас. Постараюсь кратко, одной репликой.

Есть два предварительных условия превращения ИТ-архитектора во внутреннего консультанта. Первое, архитектору есть что сказать, а второе - он не хочет принимать некоторое решение единолично, ну или не обладает такими полномочиями. Без этих предусловий тема становится не особо актуальной. А вот самих вариантов связок «что-кому-зачем» мы говорим может быть несколько. Например, забрать часть ресурсов у одних заказчиков в пользу других (тяжелый получится разговор). К счастью, есть менее сложные компромиссы.
Обсудим их на вебинаре, регистрируйтесь и задавайте вопросы!

Кто-нибудь уже попробовал NGINX Service Mesh? https://www.nginx.com/blog/how-to-choose-a-service-mesh/ Объявили о нем еще прошлой осенью, как о развитии темы NGINX Ingress Controller. Выглядит заманчиво, но ведь, не проверив, как оно там на самом деле, не узнаешь

Арчи, Смарчи и еще несколько инструментов корпоративного архитектора в еще одном свежем обзоре на эту вечно актуальную тему + гартеровский квадрант и волны форрестера (декабрь 2020 и Q1 2021 соответственно) https://welkaim.medium.com/enterprise-architecture-tooling-63cbe7ea0ad4

Кстати, один из вопросов к предстоящему вебинару снова про инструменты ИТ-архитектора. Всегда затрудняюсь с ответом на этот вопрос, помогайте!

Темы теперь включены в PlantUML https://plantuml.com/ru/theme

14 May, 2021: Introducing new !theme feature (V1.2021.6). (Thanks to Brett Schwarz for his work)

В связи с большим количеством регистраций и ограничением моей
подписки на zoom, вынужден предложить тем, кому не удалось
подключиться, youtube-трансляцию https://youtu.be/W0QZ10z1LpM На вопросы из чата YouTube тоже обязательно ответим

Хочу запустить небольшое голосование о том, какие новые требования возникают к ИТ-архитектору. С ожиданиями относительно каких навыков, артефактов, подходов и задач вам (вдруг!) довелось столкнуться? Поделитесь, пожалуйста, в комментариях к этому сообщению или в личке @mxsmirnov Заранее спасибо!

В общем-то полезные приемы презентации архитектуры предлагает Марк Ричардс https://youtu.be/pJc0l2DASpo

Вынесу ответ на один из вопросов, полученных перед вебинаром в отдельное сообщение. Собственно, вопрос традиционный, похожие были и раньше. Вопрос о взаимодействии архитектора с командой разработки. Для архитектора продукта/платформы он особенно актуален.

Говоря о взаимодействии с командой легко упустить из виду, что команда – это некоторая абстракция. Мы разговариваем не с командой, а с конкретными людьми. Соглашаемся, спорим, договариваемся. Часто под фразой взаимодействие с командой скрывается общение всего с одним человеком, например, тимлидом или даже менеджером. И это именно он боится выпускать архитектурные решения из своих рук (или полностью передоверяет их какому-то одному разработчику). Другим участникам команды выработки архитектурных решений тоже не достается, а за фразой The best architectures, requirements, and designs emerge from self-organizing teams скрываются предложения конкретного человека.

Проблема даже не в том, что архитектурные решения принимает кто-то один. Часто это квалифицированный и опытный разработчик. Проблема, если всегда происходит только так! Без обсуждений, рассмотрения альтернатив, картезианского радикального сомнения со стороны кого-то еще. Рано или поздно полезут ошибки, сформируются предпочтения, от которых непросто отказаться, сменятся технологии. Разработчики, выключенные из процесса проектирования, потеряются мотивацию и просто уйдут. Тонущий корабль с единственным капитаном на борту – узнаваемая картина legacy системы.

Решение проще, чем кажется на первый взгляд. Agile помог разобраться с процессом.

В основе управления эмпирическими процессами заложены три главных принципа: прозрачность, инспекция и адаптация - Скрам Гайд™. 

Это пойдет и для архитектуры: transparency, inspection, and adaptation. Инструмент: architecture decision record. В общем, в теме ADR еще далеко не всё сказано. И уж точно ИТ-архитектору есть чем заняться сейчас и будет чем позаниматься в будущем

Думаю, что это архитектурное описание вполне можно использовать в качестве примера https://github.com/team7katas/sysopsquad Идея со стикерами нефункциональных требований, так вообще зачетная ;-)

Слайды сегодняшнего рассказа

Запись: https://youtu.be/Jzygc6W1y-s

В продолжение темы о том, что распад приложения на модули или сервисы это закономерный процесс, поделюсь ссылкой на Криса Ричардсона про тёмную энергию и материю, которые удерживают систему от распада или же разрывают на кусочки https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Это не лженаука, просто метафора :-)

Почему ваша ИТ-система не превратится в платформу. Набросал небольшой текст на обозначенную тему. Сформулировал пять причин почему нельзя взять приложение и тупо переименовать его в платформу. Перечитал. Не понравилось. Понял, что получилось крайне субъективно и эмоционально. Публиковать не стану. Лучше попрошу помощи сообщества.

Что, на ваш взгляд, мешает ИТ-системе стать платформой? (в том значении этого слова, которое обычно используют менеджеры)

Живое обсуждение сложилось вокруг темы платформы. Спасибо.

У меня был очень простой набор соображений. 1) с технической точки зрения платформа изначальна должна содержать в себе механизмы расширений. Что это будет: история дяди Боба про инверсию зависимостей и подмену реализаций, плагины по образцу CMS-ок, обработчики запросов, команд и событий в виде микросервисов – не так важно. Если механизм расширения предварительно не придуман и не реализован в системе, то платформы из неё не выйдет 2) с точки зрения интеграции: функции, библиотеки, сервисы – это не платформа. Их можно обойти и рано или поздно разработчик вместо вашего сервиса(функции, и пр.) вызовет какой-то другой. Просто потому, что он лучше, удобней, проще, по политическим мотивам и т.д. Вы либо заставляете всех исполняться в вашем окружении, либо оставляете возможность делать небольшие расширения, конкретизирующие уже предопределенные use cases 3) с мотивационной точки зрения: отсутствие значимого конкурентного преимущества хотя бы в одной операции чревато тем, что вашу платформу просто снесут, даже несмотря на реализацию первых двух пунктов. Т.е. без ответа на вопрос: почему нельзя тоже самое, но без платформы, эта история не поплывет. Еще в паре пунктов я пока сомневаюсь

Обновил ссылку для вступления в связанную с этим каналом группу https://tttttt.me/joinchat/RjhmcXf0go0zMjli

В прошлом году подписчик нашей группы Andrei Gordienkov @kwiscakh уже участвовал в архитектурных катах 2020. И вместе с со своей командой одержал победу. Пусть и с значительным опозданием присоединяюсь к поздравлениям! 🍾👍🎉 Это круто!

не знаю как к вам всем обратиться, но хочу поделиться успехом, что моя команда, а по большей части я, победили в том архитектурном конкурсе от O`Reilly
участвовало 100+ команд, и надо бало предаставить реальное решение. В финал вышли 10 команд. Мы победили.
https://github.com/ldynia/archcolider
для рассмотрения и отзывав

Очередная история Билгинa Ибряма о модернизации унаследованных приложений https://developers.redhat.com/articles/2021/06/14/application-modernization-patterns-apache-kafka-debezium-and-kubernetes# с новыми рисунками и уже знакомыми нам идеями