Записки архитектора

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

Про свое отношение к ИИ. Впервые с ИИ столкнулся в лаборатории искусственного интеллекта СПБГЭТУ в 2001м году. То ,что мы делали там тогда ни каким образом не было похоже на то, чем стал ИИ сейчас. Шутка про набор if-ов была вполне себе релевантна. А сейчас я сижу и смотрю на систему для поддержки, где ИИ помогает квалифицировать заявки и выявлять тренды.. Кто бы мог подумать? Пару лет назад, работая CTO в банке из топ-3 максимум, где мы использовали GenAI(далее ИИшница) – это генерация unit и контрактных тестов. При всем при этом требовалось сильно вложиться в инженерку, чтобы разработка тестов не занимало больше времени чем разработка и не занимала больше времени чем работа человека руками. На тот момент почти скептически относился к искусственному интеллекту. Не мог предположить, в что это выльется сейчас. Я считал, до совсем недавнего времени, что мы сейчас в волне хайпа с ИИ, как когда-то было с бигдатой, когда её назначили серебреной пулей и пытались прилепить ко всему, что только возможно. В какой-то момент произошел роллбэк, практики и инструменты в данных устаканились и многое, что было на волне тогда признано рынком несостоятельным, тот же Hadoop, к примеру. С ИИшницей я вижу другую картину. Да, многие компании неумеренно вложились в ИИ пытаясь приладить его к любой деятельности. Но результатами «первой волны» стало появление многих практик и инструментов, крайне эффективно используемых отраслью. Для меня сейчас ИИшница – это прежде всего свобода, я могу реализовать любой проект любой сложности, описав предварительно архитектуру, за дни, а не месяцы как раньше. Вот ненавижу я front-end и главное CSS, а тут такой помощник.. За то я люблю C++ и ИИ сейчас для меня некая смесь линтера и квази-отладчика. Про тесты я уже не говорю. И теперь главное, сможет ли ИИ заменить программиста? На своей практике могу сказать -да сможет и при правильной практике проектирования уже это делает. А сможет ли заменить архитектора? Неделю назад думал, что нет. Встречались тут с коллегами из входящего в топ-1, включая руководителей архитектурной практики и совместно сделали комминг-аут. Мы все начали черпать первичные знания через ИИшницу. Обладая инженерным мышлением получать структурированные знания через LLM модели стало гораздо проще чем ранее из статей и книг.  Моя библиотека по computer-science за сотни тысяч рублей рискует оказаться сборником околохудожественной литературы или фоном на он-лайн митингах. Закончился ли золотой век ИТ? Нет не закончился, это новые инструменты которые нужно знать и уметь использовать. Проще ли будет вход в ИТ? Однозначно нет, что лично меня очень радует. Всем добра.

Странно, но все уже придумано до нас или что я узнал сегодня. Очень часто сталкиваюсь в литературе с паттернами, выстрелившими спустя десятилетия. Например, в книжке про UML 2005го года обнаружил фактически описание SDLC процесса и Contract-first подхода. Почему это взлетает сейчас и не взлетело тогда? Пади знай. Может системы были проще, может сообщество еще не созрело до инженерных практик, но факт остается фактом. Еще одна история в копилку. Помешался мир на ООП и в начале 90х появился XML. Нет ООП сейчас не умер, но нашел свое не очень узкое, но и не всеобъемлющее место в мире разработки. Неожиданно появилась ультимативная возможность ограничивать API спецификацией, а так же выносить валидацию данных из бизнес-слоя. Но XML тяжеловесен, очень затратен с точки зрения проектирования контракта и как-то потихоньку SOAP начал уступать JSON-like API. Появился Pure-JSON (богомерзкий), а дальше все пошло по нарастающей, кому интересно, почитайте про пирамиду Ричардсона (Richardson Maturity Model) .  И к чему мы пришли? Простите меня API-first бояре, но OpenApi все ближе по структурности и жёсткости ограничений к XML… Но я все не о том. Забавно наблюдать как сейчас спикеры на конференциях толпами рассказывают, как они мутят API или Contract-first подходы, как это удобно и полезно. Подразумевая, конечно, некоторую толику новаторства в своих действиях.  А тем временем API-first подходу уже более 50 лет. И это не какая-то мертвая технология из прошлого, а то, что еще и нас с вами, уважаемые читатели переживёт – SUN-RPC. Про NFS слыхали? Так вот он только по API-first и работает. При этом, куча подходов в части современной реинкарнации API-first переизобретаются заново, что равно наделению их детскими болезнями. Пост без морали, просто наблюдение с берега реки. Пейте std::cout, дышите std::cin!

Про зрелость Меня мало что интересует за пределами моей профессиональной области, и я стараюсь ограждать её трёхметровым забором от лишних знаний. Как говорил, кажется, Платон: чем больше область знания, тем больше область осознанного незнания. Поумничал. Хватит. Жизнь заставила задуматься о маркерах зрелости организаций. Под зрелостью я понимаю совокупность факторов, выражающихся в готовности организации к изменениям. От этой готовности зависит многое, в том числе и уровень людей в команде. Причём речь не столько о минимально необходимом уровне, сколько о людях, чья квалификация и опыт существенно превосходят текущие потребности. Вы можете нанять безумно квалифицированного и опытного CDTO, но если операционные процессы ведутся в Telegram, на бумаге и «по-другому у нас не принято», запуск нормальных цифровых процессов будет происходить через боль. А если основной заказчик не готов расставаться с людьми, особенно если это нужно делать массово, успех ограничится лишь лёгким тюнингом уже автоматизированного. Ну и чуть прокачаем ИТ-функции. Так, может, и человек попроще подошёл бы лучше? Могу ошибаться. Хотя, к сожалению, наблюдал такие примеры изнутри. Как сказал мой руководитель : «Я себе нравился, когда весил и 60, и 120, но люди смотрели на меня по-разному». К чему это я? Изнутри сложно оценить реальные проблемы. Ориентируясь на лучших, сложно точно понять, какой человек действительно нужен для амбициозной задачи. В итоге в вакансиях и на собеседованиях появляются требования, которые к реальной работе не имеют никакого отношения. Прочитал кучу книг про agile-трансформации и организационные процессы (зачем только). Но про метрики зрелости — если и упоминали, то вскользь. Инфоцыгане, чертовы. А как кандидату понять, не слишком ли его амбиции, навыки и знания превосходят потребности компании? Теперь понимаю: один из значимых маркеров зрелости — уровень коммуникаций. Компании, действительно готовые к изменениям, — это те, где процессы коммуникаций выстроены, формализованы и являются результатом эволюции или экспертизы. Причём с очень чёткими рамками. Формализованность не означает бюрократию — наоборот, она означает, что форма и рамки известны всем участникам, что снижает количество потерь и повышает прозрачность взаимодействия. У меня был опыт: техлид, запуск с нуля банка и телеком-оператора в Азии за 8 месяцев. Команда — менее 50 человек. Сколько у меня было встреч в день? Максимум две. Могло ли прийти приглашение на встречу без адженды? Никогда. Собиралось ли больше 5 человек? Только если это были синки, планирование или ретро. Почему так? С самого начала был выстроен производственный процесс с артефактами и активностями, включая формат собраний. Людей, нарушавших процессы, воспринимали с настороженностью. Я просто делал свою работу. Всё рабочее время — поставка value. Другой пример — банк, где у меня было 28 встреч в день. Четыре ряда в календаре. Механика: «А давайте всех соберём, кто-то окажется полезным». Рабочий день начинался в 6 утра — только с 6 до 9 можно было заняться реальной работой. Проекты затащил, около 20. Но затраты времени и сил — несопоставимы с предыдущим кейсом. Хотя и масштаб другой. Тем не менее, за счёт SAFe и выстроенного agile-процесса степень энтропии была сильно ниже, чем могла бы быть. Но основную часть времени я тратил не на архитектуру и процессы, а на договорённости, бюрократию и прочие корпоративные налоги. Мог ли я сделать продукты лучше, если бы работал в формате предыдущего кейса? Однозначно. Был ли overqualified? Не совсем — тут дело не в скилах, а в контексте. Закончилось это, как нетрудно догадаться, постоянной неудовлетворённостью и сменой работы. Хотелось техники и рывков, а не бесконечных согласований и совещаний. Пошёл бы я туда, зная заранее, как устроены коммуникации? Нет. И вопрос бы такой не встал. Последний пример. Компания не очень большая — около 5000 человек. Но всё, абсолютно всё, держится на личных очных коммуникациях. Договорились два человека — сделали фичу. Один уволился — фича в архив. Удалёнка? Нет, не слышали. Как иначе объяснить на пальцах, что тебе ну

Столкнулся с большим объемом процессных архитектурных проблем в процессе распила монолита. И на ум пришел термин "Коррупция архитектуры". Что такое коррупция архитектуры, по моему мнению: 1. Деградация архитектуры - Частичный или хаотичный рефакторинг, который оставляет «полумонолит» — части монолита все еще сильно связаны. - Дублирование логики вместо выделения общих сервисов. - Неудовлетворительное управление границами сервисов (например, один сервис начинает чрезмерно зависеть от внутренних деталей другого). 2. Антипаттерны интеграции - Модульный монолит под видом микросервисов — формально разбиение на сервисы произошло, но они по-прежнему разрабатываются и деплоятся синхронно. - Скрытая синхронность — сервисы обмениваются данными через API-запросы, но не задумываются о деградации и отказоустойчивости. - Сервисная паутина — усложнение зависимостей между сервисами, что делает систему хрупкой. 3. Политическая коррупция архитектуры - Архитектурные решения принимаются не на основе технической целесообразности, а в угоду внутренним интересам отдельных команд или лидеров. - Игнорирование стратегического видения в пользу краткосрочных решений. - Внедрение инструментов и подходов «для галочки», а не для реального улучшения архитектуры. 4. Нарушение автономности команд - Централизованный контроль, мешающий независимой поставке сервисов. - Введение бюрократии, замедляющей эволюцию архитектуры. - Отсутствие четких границ владения сервисами (ответственность за один сервис размазывается между несколькими командами).