Весь год фабрика мысли нашей компании😎️ работала на полную мощность. Мы глубоко ныряем в смыслы, чтобы потом было легко на уровне тактики.

Каждый из основателей развивал методы и сообщества в своём направлении:
1. Александр Бындю https://xn--r1a.website/byndyufeed/444
2. Андрей Шапиро https://xn--r1a.website/how2scheme/309
3. Руслан Сафин https://xn--r1a.website/rsa_enc/356

♦️Самый большим общим шагом стало описание фреймворка для проектирования социо-технических систем https://byndyusoft.com/productanalysis. Что из четырех частей этого Фреймворка уже используется в вашей компании?

🤩От всей компании Byndyusoft😎️ желаем вам вкладывать время и жизненную энергию только в что-то действительно стоящее! С наступающим Новым годом 🎄

Денис Бесков сделал подробный разбор моего канала, за что ему огромное спасибо! Было очень приятно читать теплые слова, а практичным советам Дениса я обязательно последую в новом году! 🎄

Читать разбор

А какие у вас, как подписчиков, есть пожелания и рекомендации по моему каналу? Чего бы хотелось, каких тем? Что уже хорошо, а на что обратить внимание?

Всех ещё раз с наступающим! 🥂 ❤️

Приветствую всех в новом году! 🎁

Ещё перед самым новым годом обновили описание нашего фреймворка, которым мы в Бындюсофт 😎️ проектируем и в последствии реализуем сложные ИТ-продукты или даже социо-технические системы.
А именно — добавили описание 4️⃣-го этапа — проектирования архитектуры.

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

Обычно я выделяю 5 основных разрезов ИТ-архитектуры и её реализации при проектировании продуктов:
1. Архитектура ИТ-инфраструктуры
2. Схемы информационных потоков
3. Оркестрация бизнес-процессов
4. Микросервисная архитектура решения
5. Дорожная карта встраивания архитектуры решения в текущий ландшафт архитектуры предприятия

Чуть нагляднее — по ссылке.

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

Всех ещё раз с наступившим! ❤️

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

Кроме того, можно присоединиться на открытые встречи спикеров (я как раз и буду на них представлять программный комитет (ПК)), послушать чего мы ждем, обсудить или спросить про свои идеи:
📆 28 января 18:00 — онлайн-встреча с ПК CTO Conf, встреча открытая по предварительной регистрации
📆 29 января 18:00 — онлайн-встреча с ПК TechLead Conf, встреча открытая по предварительной регистрации

CTO Conf — абсолютно новая конференция для технических директоров, в которой я отвечаю за секцию технологий.

Про родные края я тоже стараюсь не забывать — мы начали подготовку к UWDC 25! 🏔

И с особой любовью и гордостью расскажу про свою новую позицию в CodeFest 🎙☺️. Нет-нет, я все так же занимаюсь архитектурными докладами для Кодфеста, но теперь не только!
На юбилейный 15й CodeFest мы готовим что-то по истине грандиозное — что-то, чем хотим на самом деле бустануть индустрию, насколько это возможно с позиции организаторов конференций. Это секция Будущего!

Понимание будущего теперь в том, что нет никакой границы между сегодня и завтра, что будущее уже здесь, что мы в него вступили и в нём живём. Действительный прорыв в понимании и концепциях в том, чтобы признаться себе и уже начать жить в новом. Сделать смелый переход: от отложенной жизни и взгляда вперёд к жизни в моменте и взгляду вокруг. У нас всё для этого есть. Итак, добро пожаловать — Будущее! Устраивайтесь поудобнее.

Полный вижн секции: https://15.codefest.ru/themes#future

Если вы проектируете и создаёте архитектуры проектов, меняющих мир — срочно подавайтесь с докладами и/или пишите мне! 🚀🚀
Ведь прямо сейчас мы создаём будущее и меняем настоящее 🧑‍🚀

15 февраля впервые в России (😅) представлю выведенный мной Принцип каскадного снижения связанности! 🚀

Описание и тезисы первой версии доклада (в 🇰🇿) публиковал ранее.

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

Обновлённую версию доклада расскажу 15 февраля в рамках онлайн-конференции Analyst Marathon #12:
https://xn--r1a.website/Analyst_maraphon/323
(кому нужны промокоды и скидочки (их ограниченное количество) — пишите в комментарии или в личку)

🌌🌌🌌🧑‍🚀

Очередное сообщение в корпоративном чатике о том, что "* * * прилёг" и теперь у нас не работает часть систем, застало меня за чтением советского (⭐️!) ГОСТа 27.002-89 "НАДЕЖНОСТЬ В ТЕХНИКЕ".

1.1. Надежность
Reliability, dependability
1.2. Безотказность
Reliability, failure-free operation
1.3. Долговечность
Durability, longevity
1.4. Ремонтопригодность
Maintainability
1.5. Сохраняемость
Storability

ничего не напоминает? 😏

Видимо верно говорят, что сейчас нет ничего нового, а есть только советские разработки на бумаге, до которых сейчас наконец-то дошли руки 😉

ГОСТ предлагает чёткие определения понятий и классификацию состояний объектов и видов отказов, а также конкретные формулы расчета вероятности отказов.
В ГОСТе говорится о сложных технических объектах, которым свойственен износ и срок наработки. В этом плане, наверное нельзя один к одному перенести методики расчета на программные компоненты распределенных систем (наверное вы уже догадались, что я к этому клоню), т.к. те же наши всеми любимые микросервисы падают скорее не из-за временно́го износа, а по причине внесения изменений или внешних факторов (хотя наверное это всё тоже можно как-то наложить на шкалу времени и придумать формулы — было бы интересно попробовать 🤔).

Но всё чаще в публичных постмортемах ⚰️ крупных сбоев первопричиной становится выход из строя как раз физического оборудования (недавно где-то было про выгоревший порт коммутатора), что как раз поддаётся прогнозированию и расчётом по формулам из прошлого тысячелетия 📜

Т.е. в пресловутый расчёт количества девяток после запятой можно попробовать включить давно известную теорию, правда при этом придётся уже на уровне архитектуры железа стрясти с производителей необходимые параметры, либо проводить испытания самим 😅.

Не факт, что на практике это было бы целесообразно для большинства проектов, но если от отказа вашей программно-аппаратной системы много чего критичного зависит.. хотя наверное вы уже и так тогда знакомы с данным ГОСТом (собственно почему я его и изучал 🙃).

В целом, возвращаясь к отказоустойчивости именно софта: если у вас достаточно много статистических данных по различного рода отказам — ради интереса можно попробовать применить ГОСТовские формулы для расчета различных показателей отказоустойчивости (и наложить потом результаты расчетов на реальные факты и время отказов 👩‍🎓).

И в любом случае, независимо от накопленной статистики, я советую всем проводить учения и тесты своих систем на отказоустойчивость и восстановления после сбоев. У меня есть отдельная статья про проектирование отказоустойчивости и её измерении: https://habr.com/ru/articles/764904/

ГОСТ

Всем стабильных систем 🌀, и всех с наступающим 💗!

[пятничный пост]

Вчера в беседе внезапно вывели метрику стабильности и отказоустойчивости систем ))

Суть в том, что у меня в холодильнике достаточно долго лежала баночка брендированного подарочного энергетика с одного из давних Хайлоадов. Лежала она на случай внезапного падения прода в разгар ночи — точнее на случай необходимости взбодриться и оперативно тушить пожары и поднимать всё упавшее.

Так вот, эту баночку пришлось выкинуть, т.к. у энергетика вышел срок годности 📆
И на неделе я купил новую и положил в холодильник на тот же случай.

Получилась вот такая метрика стабильности наших систем, и хороший показатель этой метрики 🕶

Принял участие в записи аудио-подкаста Цифровые голоса, побеседовали про мою любимую тему — Архитектуру как код 😊
https://rutube.ru/video/a0948a611c85b4f284f8e1695099815c/

Тайминг и этапы беседы по мнению YaGPT 🤖:

00:00:05 — Введение в архитектуру как код
00:00:39 — Что такое архитектура как код
00:02:49 — Преимущества архитектуры как код
00:04:48 — Инструменты для архитектуры как код
00:06:07 — Тестирование архитектуры
00:08:06 — Документирование и создание новых архитектур
00:09:15 — Примеры тестов
00:11:10 — Проектирование нового проекта
00:12:09 — Архитектуры и итерации
00:12:59 — Повторное использование элементов
00:15:29 — Нотации и инструменты
00:17:03 — Языки и инструменты
00:20:31 — Применение AaC в проектах
00:22:59 — Проблемы с асинхронной связью
00:23:58 — Внедрение автоматизации
00:25:09 — Рекомендации для начинающих
00:25:47 — Тестирование архитектуры
00:26:47 — Заключение

🎧🎧🎧

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

В целом, термин "метадокс" уже хорошо гуглится, к примеру краткое видео с его определением от одного из авторов: https://www.youtube.com/watch?v=b9Nt_Ipo230

Если вкратце, суть метадокса насколько я его понимаю — в переходе от бинарного противоречия к тернарному и в описании неких промежуточных состояний, уходящих во фрактальную бесконечность.

Думаю, всё будет ясно на примере.

В вершины базового метадокса (треугольника) поместим 3 основных разных подхода к программированию на текущий момент (всё сугубо только на мой субъективный взгляд):
Классическое программирование — Искусственный Интеллект (ИИ) — Low Code.

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

Теперь подумаем, что есть что в современном многообразном ландшафте нашей айтишечки. Я предложу свои варианты (с разной степенью субъективной уверенности в них) и буду рад услышать альтернативные предложения и рассуждения.

🔼Классическое программирование с оттенком ИИ — имхо, это таблицы решений, которые с одной стороны максимально чёткие в плане классического программистского если-то, с другой — чуть приближены к математической магии машинного обучения (к примеру, к тем же деревьям решений)

Идём дальше.

🔼Классическое программирование с оттенком Low Code — это различные DSL, т.е. языки программирования приближенные и заточенные под конкретную доменную область. Этакий промежуток между универсальным языком программирования и LowCode'ом )

🔼И наконец, классическое программирование с оттенком классического программирования — на мой взгляд, это функциональщина ) Оргазм любого тру хардкор олдскул программиста )
〰️〰️〰️〰️

Думаю, логика понятна. Попробуем заполнить и следующие вершины.

🔼ИИ с оттенком ИИ — это наш всеми ожидаемый AGI: сильный (или общий) ИИ. Технологическая сингулярность, точка невозврата и вот это вот всё 👁

🔼ИИ с оттенком классического программирования — это условно алгоритмические виды машинного обучения, например, деревья решений, результат работы которых (в отличие от нейросетей) можно интерпретировать в виде понятной причинно-следственной цепочки вычисления осмысленных условий.

🔼ИИ с оттенком Low Code — тут пока сложно, возможно соответствующих ярких представителей категории пока ещё и не изобрели (как и рядом стоящих Low Code с оттенком ИИ).. Я бы сюда отнёс в целом программирование с помощью LLM-моделей (всякие копилоты): ты ей промт на белковом человечьем, а она тебе в ответ код. В таком подходе программировать можно и не уметь, но чуть-чуть (Low) придётся.
〰️〰️〰️〰️

И последний треугольник второго уровня (коих может быть сколько угодно) — Low Code.

🔼Начнём с трудного: Low Code с оттенком ИИ — как и писал выше, с одной стороны я не вижу тут одного яркого представителя или технологии (возможно это значит что ниша ещё не до конца сформирована). С другой — в свои Low Code платформы не пытается встроить ИИ сейчас только ленивый: мы установили одну хайповую технологию в другую хайповую технологию 🏎. Пусть тут будут эти многочисленные ИИ-конструкторы, якобы создающие прототипы CRM-систем по экспорту задач из трелло.

🔼Low Code с оттенком Low Code — ещё одна недостижимая точка, мечта всех маркетологов — No Code 🤤

🔼Low Code с оттенком классического программирования — различные BPMN-движки, прокидывающие мостик между наглядностью визуализации и суровыми энтерпрайзными json'о-перекладывателями микросервисами.
〰️〰️〰️〰️

Вывода не будет (пока). Предлагаю вместе порассуждать над вариантами вершин всех треугольников, покидать альтернативы.

Прежде чем продать понять что-то ненужное сложное, нужно сначала купить описать что-то сложное
🧠

Ранее писал о нашем процессе или фреймворке, которым подходим к проектированию ИТ-продуктов и социо-технических систем (https://xn--r1a.website/rsa_enc/359), ➕ и в прошлом посте про академию (⬆️) есть материалы по всем этапам процесса.

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

Как архитектор, по возможности я участвую в таких активностях, и даже иногда их веду. А для этого нужно знать методы анализа досконально.

Идущие первым этапом нашего анализа выявление бизнес-целей и создание стратегии их достижения — мы прорабатываем с помощью метода "Карта гипотез". О нём я кратко расскажу на конференции в московской торгово-промышленной палате, где я состою в экспертной группе (как я попал и чем занимаюсь в экспертной группе при ТПП — истории для отдельных постов ☺️🏮).

Технология «Карта гипотез» для создания стратегий бизнеса и личностного роста. Метод позволяет связать цели бизнеса и конкретные задачи исполнителей через гипотезы-идеи.
Аспекты:
• как преодолеть разрыв между потребностью качественной стратегии и рамками возможностей руководителей создавать гениальные стратегии
• специфика и возможности технологии «карта гипотез»
• примеры разработки стратегий на реальных кейсах

Полную программу конференции прикреплю комментарием, также она доступна по ссылке:
Лучшие бизнес-практики для адаптации и устойчивости бизнеса в текущих реалиях

Участие бесплатное по предварительной регистрации.

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

👍

Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎

Теперь и в виде статьи на Хабре! Встречайте, выведенный и сформулированный мной Принцип каскадного снижения связанности: https://habr.com/ru/articles/894766/

Если понравится статья — буду рад вашим ➕⬆️ , это позволит увеличить охват читателей статьи ☺️

Весенний сезон оффлайн и онлайн выступлений выдаётся очень насыщенным 🍃

Сегодня я выступил в Торгово-промышленной палате. А уже завтра на next conf расскажу чуть адаптированный для системных аналитиков свой доклад про тестирование архитектуры as Code:
Переведём архитектуру в as code и проверим её качество тестами!

В апреле на конференции Systems Design сделаю по этой же теме уже более подробный мастер-класс с написанием кода тестов на архитектурные принципы:
Тестирование архитектуры программного обеспечения

И в Екатеринбурге на Dump расскажу об инструментах для измерения архитектурных метрик на примере проверки своего принципа проектирования:
Принцип каскадного снижения связанности и его проверка измерением архитектурных метрик

Буду рад всех видеть и со всеми пообщаться ❤️☺️

🥳 Сегодня нам исполнилось 13 лет!

Изначально мы собрались вместе на любви к инженерному делу. Прошли годы, нас уже 60 человек в трех городах, но суть компании осталась неизменна – практика и развитие инженерного дела.

Мы хотели успеть оформить результаты сделанного нами на странице Академии и успели https://byndyusoft.com/academy. Собрали в одном месте две книги и методы, которые выводят на новый уровень создание стратегии, анализ и проектирование социотехнических систем. Впереди еще много планов, например, вторая книга про Антихрупкость в IT, которая объединит знания трех основателей компании https://xn--r1a.website/byndyufeed/451.

Мы благодарны сообществу инженеров, аналитиков, управленцев за поддержку! И, конечно, благодарны нашим заказчикам за желание создавать сильные решения, что дает нам возможность делать великолепные инженерные конструкции в IT.

Всем спасибо и нас с праздником 🥳

Всем привет! За последний месяц я слетал в отпуск (на турнир по шахматам с кубиками 🎲) и выступил на четырёх конференциях 😅☺️

Как уже неоднократно писал и говорил — на это дело меня заряжают и драйвят ваши отзывы! Отзывы читателей и слушателей 💕. Всё чаще и чаще ко мне подходят незнакомые (а отходят уже знакомыми) люди, говорят что слушали/читали мои доклады/статьи, благодарят и рассказывают что у них удалось и не удалось внедрить у себя на проектах из моих материалов. Кто-то просто подходит пожать руку и сказать спасибо — это невероятно приятно 🤝🥰

Приведу пару отзывов с одной из конференций:

Это был самый отличный доклад. Сохранила все ссылки. Динамичный, интересный, полезный. Обаятельнецшмй автор. Актуальные задачи. Короткое время разраьотки. Не перегружено, в тоже время есть ссылки на гит и статьи. Респект! Используем и Кубернетес, и схемы в виде кода. Прямо очень понравилось. Спасибо вам, вы сделали мой день :)

Чувствуется высокий уровень экспертизы докладчика. Очень понравилось

Бывает, конечно, и такое — куда без этого (иначе было бы подозрительно 😅):

Сильный выход за тему, очень нагруженно, несколько раз засыпал

Особенно хочу отметить Максима Цепкова — он выступает сам и публикует конспекты лучших докладов конференций. И уже не впервые мне приятно у Максима читать про свой доклад ☺️

На конференциях я рассказывал про наши продвижения в понимании принципа каскадного снижения связанности (КСС) (ссылка на статью) и обновлениях в репозитории AaCT.
Пока совсем кратко:
💡 выпустили первую версию анализатора архитектур, который строит отчёт и выдаёт архитектурные метрики (пока совсем базовые):
https://github.com/Byndyusoft/aact/blob/main/src/analyzer.ts
💡 пример его использования можно посмотреть в новом переработанном и более глубоком тесте на соблюдение принципа КСС: https://github.com/Byndyusoft/aact/blob/main/test/ccr.test.ts

Обязательно напишу отдельно про обновления подробнее и выложу видео с выступлений, когда они появятся. А пока можно полистать слайды — закину файл комментарием к посту (про метрики и тест — с 39го слайда).

И пару слов про дальнейшие планы:
🎤 24 мая выступлю в Челябинске на UWDC
🎤 6 июня — на МТС True Tech Day в Москве
А между этими датами буду как организатор на CodeFest, TechLeadConf и CTO Conf в Новосибирске и Москве.
Если доберётесь — буду очень рад всех увидеть 😘🥰!

Всем весны! 🍀

После одного из выступлений мне задали очень хороший вопрос — применим ли мой принцип каскадного снижения связанности только в софте (микросервисах и монолитах) или в целом и в других сферах жизни?

Скажу честно — к такому вопросу я готов не был 😅. Сходу на ум пришёл пример с организацией разделения компании на отделы. Представим, что в некоем офисе сотруднике разделены на отделы и у каждого отдела свой этаж (или комната). При этом предполагается, что коммуникаций между сотрудниками отдела будет больше, чем с коллегами из соседних отделов — что логично, проще спросить у Васи, который за соседним столом, чем идти в другой отдел по лестнице. Ничего не напоминает? 🙂 Те же связанность (coupling) и прочность (cohesion). Прочные и частые коммуникации внутри отдела, при более редких внешних.
При этом, если приходится постоянно бегать между этажами, а взаимодействий с соседом по кабинету почти нет — явно эффективность процессов страдает (связанность выше прочности), и это скорее всего сигнализирует о неправильном распределение сотрудников по отделам (и/или процессов и ответственности между отделами).

Мой принцип будет говорить о том, что соотношение коммуникаций не только внутри и между отделами должно быть "правильным", но и взаимодействия на разных уровнях бизнеса (к примеру, команда-отдел-филиал-компания-группа компаний) должны соответствовать этому самому уровню взаимодействия 😏

На мой взгляд, получился неплохой пример из жизни 😌

А сегодня хочу ещё порассуждать о химии, в которой я вообще ни разу не специалист 😅.
Как будто бы при объединении атомов в молекулы, а молекул в более сложные структуры — работает всё тот же принцип, что наверное логично 🙂
С массивными атомами всё вроде понятно — у них сильная внутренняя прочность (упрощая — большое количество протонов и электронов), поэтому они легко объединяются в сложные молекулы с множеством связей с другими атомами (связей с другими атомами всё равно меньше, чем связей частиц внутри).
Посмотрим на лёгкие атомы — водород (упрощая — 1 внутренняя связь) и бериллий (4 внутренние). Атом водорода в молекулах имеет всегда только одну внешнюю связь (в молекулы воды каждый из двух атомов водорода связан с единственной молекулой кислорода, в спирте — единожды с углеродом или кислородом). Т.е. внешних связей не больше чем внутренних.

Для атома бериллия я тоже не смог найти нарушения принципа — даже в органической молекуле оксид-гексаацетата бериллия у каждого атома тоже связей не больше четырёх (см. картинку 🙂).

В химии и физике нам намного проще — соблюдение законов контролирует сама природа (ну или движок матрицы 📺). Жаль, что в ИТ при проектировании сложных систем нам приходится делать это самостоятельно. Или не жаль 💚

Продолжим рассуждения предыдущего поста, в котором я перекладывал каскадное снижение связанности на организационную структуру компаний и даже на молекулярную химию 🤓

За полгода я уже достаточно много где рассказал про предлагаемый мой принцип — и много где после доклада мне говорили, что мои идеи являются следствием (или даже просто копией) постулатов всем известных (😉) теории систем и теории графов. Это обсуждали и в Алматы, и в Екатеринбурге, и в Новосибирске, и в Челябинске (чувак признался, что был на моём докладе в КЗ и пришёл на его продолжение в Че ☺️ ), и в Москве, и в интернете (в том числе по мотивам предыдущего поста).
Пользуясь случаем, выражаю огромную благодарность всем, кто задаёт вопросы, комментирует и подходит/пишет обсудить ❤️.

Сразу скажу честно — ранее, я весьма поверхностно был знаком именно с "теорией" теории систем. Хотя с переложением её на практику, как оказалось, сталкивался достаточно часто — и в материалах по системному подходу, и в различных статьях по Coupling & Cohesion в ИТ.

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

Но сейчас хочу порассуждать не только об этом.
Постепенно (нет 🙃) подведу к теме концептуального будущего ИТ-архитектуры.

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

Я вот всё время пишу и говорю, что мы как архитекторы должны бороться со сложностью, т.к. она убивает проекты и т.д. Но не ограничивают ли наши методы борьбы с ней прогресс развития ИТ?
Заметьте (❗️), не сама борьба тормозит прогресс, а несоответствующие текущему этапу развития методы борьбы со сложностью.

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

Что это вообще такое ❓

Мне очень нравится краткие формулировки описания этих терминов у С.Б. Переслегина, которые и процитирую:

В чём суть средового подхода — вы имеете дело с системой, в которой обязаны учитывать бесконечное количество элементов связи...
Базовое движение в средах — это волновые процессы. Если когда вы воздействуете на систему — она реагирует на вас принципом Ле Шателье (обратной связью — прим. моё), то когда вы воздействуете на среду — она рассеивает ваше воздействие через генерацию волн.

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

Среда — это система с бесконечным количеством степеней свободы.

Видео Сергея Борисовича про системный, средовой и сферный подходы: https://www.youtube.com/watch?v=Rn50DfXpATs

А вот до ИТ-сферы и соответствующего сферного подхода в ИТ, на мой взгляд, нам ещё далеко )

Интересно, как скоро придётся менять название канала на "Архитектура распределённых сред"? 🙃
Хотя думаю, что прилагательные "распределённые" неприменимо к средам. Скорее назову канал примерно так: "Архитектура по средам" 😀