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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👍

Наконец-то представляем всем "Академию Бындюсофт"! 🧑‍🚀

Пока стартуем со страницы, где собрали наши подходы и методы стратегирования, анализа и проектирования:
https://byndyusoft.com/academy

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

Первый шаг Академии Бындюсофт в виде сборки ссылок на все полезные материалы и ресурсы, сделан!
🚀🖤

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

В целом, термин "метадокс" уже хорошо гуглится, к примеру краткое видео с его определением от одного из авторов: 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://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 — Заключение

🎧🎧🎧

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

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

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

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

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

Очередное сообщение в корпоративном чатике о том, что "* * * прилёг" и теперь у нас не работает часть систем, застало меня за чтением советского (⭐️!) ГОСТа 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/

ГОСТ

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

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

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

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

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

🌌🌌🌌🧑‍🚀