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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки для финансового сектора IBS, более десяти лет создаю сложные ИТ-решения для лидеров рынка, а также преподаю в Учебном центре IBS.

Недавно мы провели внутрикорпоративный эфир Ask Me Anything («Спроси меня о чем угодно»). Коллеги могли задать любой вопрос о работе архитектора ПО. В этой статье поделюсь самыми интересными и неожиданными из них.

Что общего у проектирования ИТ-системы и дома?

Сравнение с домом я слышу довольно часто — в обоих случаях нужны десятки планов и схем, один чертеж ничего не объяснит. Но ключевое отличие — в «дверях». У дома дверь чаще всего одна, а у ИТ-систем их много.

Первая — это интерфейс. Пользовательский, API, REST, протоколы интеграции — именно через них внешние люди и сервисы «стучат» внутрь. Вторая — команда. Разработчики, поддержка, аналитики: именно они принимают обратную связь и объясняют, как система устроена.

И здесь есть практический вывод: архитектор должен знать, у кого какие контакты, кто за что отвечает, и держать эту матрицу всегда актуальной. Без «реестра дверей» даже самая красивая схема превращается в мертвый документ.

Как отличить архитектора от художника?

Художник работает один: нарисовал петуха — вот он и есть.

Архитектор так не может. Его идеи проходят через десятки людей, и, если он замкнется в башне из слоновой кости, команда обойдет решения стороной.

Архитектура ПО — это про коммуникацию и умение вести команду. В отличие от художника архитектор редко делает то, что хочет лично: он подстраивается под требования бизнеса, клиентов, пользователей. В этом смысле архитектор ближе к театральному режиссеру: актеры могут спорить, сцена может сломаться, но именно от режиссера зависит, будет ли спектакль работать как единое целое.

Какие трудности при разработке архитектурного плана поста охраны оказывают наибольшее влияние на проект?

С помощью этого шуточного вопроса можно наглядно показать, в чем заключается архитектурный подход. Разработчик, услышав «пост охраны», сразу предлагает решения: камеры, прочные стены, удобное кресло и турникеты. Но архитектор обязан остановить этот порыв и начать со сбора требований.

Итак, нам нужен контроль периметра. Но что такое периметр? Нужны ли нам вообще камеры, или охранник видит все помещение со своего поста? Должен ли охранник знать, что находится внутри периметра? Какие объекты мы должны распознавать? Какой режим доступа и сколько всего сотрудников? Каждое уточнение рождает новые сценарии — вплоть до того, как реагировать на кошку, пробежавшую мимо. И только после этого появляются тактики: разделение обязанностей, двойная проверка («four-eyes check»), автоматизация отдельных процессов. Уже на базе тактик можно подбирать технологии — от зеркал до компьютерного зрения.

Главный вывод: архитектура — это не про «поставить камеры», а про последовательный сбор требований и сценариев.

Если бы вы проектировали кофемашину для сотрудников, какие принципы бы применили?

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

Первая задача — приготовить идеальный кофе для каждого сотрудника отдела.

Ключевое слово здесь — «качество». У каждого сотрудника свои предпочтения: кто-то пьет черный без молока, кто-то миндальный раф. Значит, система должна уметь идентифицировать человека и готовить для него по персональному рецепту. Более того, нужен сбор обратной связи, иначе как понять, понравился ли напиток? Здесь возникает идея с мобильным приложением или QR-кодом для оценки. Получается, что «идеальная кофемашина» — это не только про молотые зерна, а про персонализацию и постоянное улучшение.

Вторая задача — приготовить утренний кофе для 10 000 сонных и нетерпеливых разработчиков.

Если представить 100-этажный небоскреб, где на каждом этаже по сотне разработчиков, простая арифметика показывает: одной машины не хватит, нужно как минимум 200, по две на этаж. Тогда все сотрудники получат свой утренний кофе в течение часа. Это решение в лоб, но оно скучное и не самое оптимальное.

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

Эти два кейса показывают разный приоритет. В первом — персонализация и качество, во втором — масштаб и производительность. И именно такой выбор приоритетов архитектор делает каждый день.

Можно ли войти в архитектуру ПО, минуя путь разработчика и не зная разницы между Golang и .NET?

Короткий ответ — нет. Длинный — тоже нет, но с нюансами.

Архитектору нужно понимать, какие решения вообще реализуемы и сколько они стоят в терминах времени и ресурсов. Без опыта разработки вы рискуете строить «воздушные замки»: красиво на схеме, но команда все равно обойдет это решение, потому что оно невыполнимо.

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

Как убедить заказчика, что Excel — не универсальная система управления базами данных?

Excel — прекрасный инструмент. На старте бизнеса он реально лучше любой базы данных: все просто, дешево и удобно.

Проблемы возникают при масштабировании. Один предприниматель справится с Excel, а сто человек одновременно — уже нет. Здесь и появляется база данных, транзакции, распределение нагрузки.

Поэтому спорить с заказчиком про Excel бессмысленно. Нужно показать: Excel хорош для одного, но если пользователей больше, он ломается. А значит, база данных — это не замена Excel, а следующий уровень зрелости.

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

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

Одновременно по-прежнему остаются вопросы архитектуры, но к ним примешиваются вопросы обеспечения процессов разработки, безопасности, экономические обоснования, целесообразность той или иной задачи. Технический директор думает не только про «красоту» решения, но и про его окупаемость. Экономический смысл приобретают не просто некие мифические требования бизнеса, а реально измеримые показатели. Мне эта часть интересна, она ближе к бизнесу.

На эволюцию какого биологического вида больше всего похожа эволюция архитектуры ПО?

Это был мой любимый вопрос AMA. Отвечу в двух версиях.

Версия архитектора
Архитектура ПО проходила этапы, похожие на эволюцию живых существ:

1. Продукты, созданные одиночками, — как крокодилы в болоте.

В начале развития программного обеспечения архитектура была в значительной степени делом одного человека. Программисты-математики работали в ограниченном контексте и создавали изолированные решения, которые могли удовлетворить определенную потребность. Зачастую они работали без каких-либо специфических стандартов или выверенных процессов разработки. Как и крокодилы в своем болоте, первые программисты были единственными хозяевами своей экосистемы, только они в ней разбирались и готовы были «съесть» любого, кто посмеет приблизиться.

2. Монолиты — как киты.

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

3. Микросервисы — как муравьи или пчелы.

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

Версия ИИ
Ради интереса задал тот же вопрос нейросети — и ответ получился даже изящнее. Первичную монолитную архитектуру она сравнила с бактериями: одна клетка, все процессы внутри. Следующий шаг — эукариоты: ядро и органеллы, как модули внутри архитектуры. Затем многоклеточные организмы — это клиент-серверные системы. А современные экосистемы микросервисов — это уже целый биосферный уровень, где виды появляются, исчезают, но жизнь продолжается за счет разнообразия. Честно признаюсь: я бы сам до такой аллегории не додумался.

Сессии формата Ask Me Anything выходят за рамки «чистой технички». Архитектура ПО — это не только схемы и API, но и метафоры, масштабирование, работа с людьми. Именно поэтому такие дискуссии помогают увидеть профессию в новом свете.

Задавайте свои вопросы в комментариях — постараюсь тоже на них ответить!