Интересно, будет ли эта история иметь какое-либо продолжение?

В коротком сообщении о выходе сразу двух версий web-клиента мессенджера telegram, имеющих схожий набор функций, сказано: мы верим во внутреннюю конкуренцию.

Что ж, мы все в неё верим! Но пока другие разработчики не начнут поступать так же, это выглядит скорее эксцентричной выходкой, чем перспективной практикой

Эту картинку я утащил из заметки Gregor Hohpe Thinking Like An Architect Part 2: Architects See More Dimensions и вспоминаю её всякий раз во время жарких дискуссий в соц.сетях.

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

Если же ваш оппонент считает вас идиотом, из-за того, что вы не разделяете его истинное и научное убеждение о вращении Земли и других планет нашей системы вокруг Солнца, то это исключительно его проблема. (Кстати, можете упомянуть, что одна из планет солнечной системы вращается не вокруг Солнца)

А вот и обещанный подкаст с расшифровкой https://www.infoq.com/podcasts/architecture-design-trends-report/ Мне показалось, что участники разговора постоянно что-то упускают и сами это чувствуют. Будто забыл какое-то нужное слово. И сам его не можешь и собеседники не готовы подсказать. Впрочем, подкаст большой, надо еще раз будет к нему вернуться

Зацепившись взглядом за этот твит Gregor Hohpe https://twitter.com/ghohpe/status/1386808304987475972 я набрел на длинную, но интересную дискуссию с банальным заголовком Has UML died without anyone noticing? (см. здесь https://news.ycombinator.com/item?id=26934577 и здесь про используемые диаграммы: https://news.ycombinator.com/item?id=26940593)

Интересна она набором неочевидных гипотез относительно снижения популярности UML, например таких, как изменение модели поставки ПО или упоминаниями идей типа GML - Galactic Markup Language от Кента Бека :-)

Минутка графомании: для чего нужна ИТ-стратегия

Существует множество банальных ответов на этот вопрос: поддержать стратегию бизнеса, оптимизировать использование ресурсов, расширить, углубить и пр.

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

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

Вещь, которая выстроит динамическое равновесие между деньгами, людьми, изменениями, клиентами, партнерами и регуляторами называется… правильно, стратегия. А её воплощением в нашей материальной реальности занимается архитектура предприятия

Набросал анимированную картинку к рассуждениям выше
PS: обновил

Большая, быть может даже чуть-чуть занудная статья, в которой есть пожалуй все важные вещи для понимания распределенных систем. Статья с очевидными историческими параллелями о хранении данных на внешних запоминающих устройствах в старые добрые времена https://queue.acm.org/detail.cfm?id=3236388

Хочу вытащить из чата "Мастерская ИТ-тренера" тему про конструкторов (вероятно, наиболее близкий английский термин design engineer). Может и правда solution architect в большей степени именно конструктор, воплощающий новые продукты и фичи из имеющихся ресурсов и возможностей организации. Как вы думаете?

Мне кажется, нужно вообще забыть слово «архитектор» применительно к решениям (продуктам)

Над решением работает команда конструкторов. Конструкторы ПО (как мин бэк и фронт), конструктор инфраструктуры, конструктор ИБ

Руководит этой командой Главный конструктор - архитектор решений

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 Идея со стикерами нефункциональных требований, так вообще зачетная ;-)

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