Правило 15. Архитектура - это инструмент управления
Архитекторы часто предстают окружающим бесполезными рисователями кубиков, которые ничего не решают и лишь зря тратят время команд разработки.
К сожалению, во многих случаях это действительно так. И виноваты в этом сами "архитекторы", то есть люди, которые стараются такими казаться. Архитектурная практика из-за хайпа и TOGAF превратилась в профанацию. Вместо инженерной работы эти люди занимаются разработкой конвенции о нейминге, о чём я уже писал здесь.
Многие из таких "горе-архитекторов", оправдывают себя тем, что у них нет реальной власти, их не слушают, они не имеют блокирующего слова и так далее по списку. И отчасти это даже является правдой, ведь архитекторы - это поддерживающее подразделение, такое как HR, бухгалтерия или отдел сопровождения ИТ (я о тех, кого зовут починить принтер). По крайней мере, если только вы не софтверная компания, продукт которой - это софт. В этом случае архитекторы становятся частью основного производства и тогда они будут обладать реальной властью, но всё равно ограниченной.
Архитекторы как и другая команда разработки остаются технической командой, но решения о развитии бизнеса принимает руководство компании, которое руководствуется другими соображения (прежде всего экономическими), нежели техническая команда.
Что уж и говорить об архитекторах, которые работают в традиционных секторах экономики и находятся ещё дальше от основного производства.
Такие архитекторы всегда будут жаловаться на недостаток власти и полномочий, а получив власть, превратят процесс производства в в разговор о том, что нужно исправить в производственном процессе. Власть не дают, власть берут!
Я придерживаюсь усвоенной ещё в юности типизации власти:
- Власть позиции (должность в организации с возложенными на неё функциями)
- Власть личности (влияние на людей через личные взаимоотношения)
Серые кардиналы относятся ко второму типу власти и как показывает история, чаще всего обладают куда большим могуществом, чем люди, назначенные на должности и обладающие формальными полномочиями.
Архитекторы крайне редко обладают властью позиции в силу описанных выше причин, но хорошие архитекторы обладают огромной властью личности. Такие архитекторы смогут заблокировать или дать ход почти любому проекту через людей, обладающих властью позиции. И именно к такой власти и стоит стремиться любому архитектору.
И именно через власть личности архитектора архитектура начинает влиять на организацию.
Однажды сказал мне CTO одной крупной компании: "Архитектура внедряется в компанию через боль".
Эта боль выражается в снижении прибыли, повышении затрат, потере доли рынка и так далее. То есть, когда организация начинает нести потери, возникает потребность в чёткой структуре — архитектуре. Это непростая задача — помогать организации преодолевать кризис, но именно в этот момент правильное использование архитектурных практик может выстрелить и поднять архитекторов в глазах топ-менеджмента, а то и собственника.
Какие инструменты влияния есть у архитектора?
Я крайне не люблю абстракции типа «правильные технологии» и «подходящие паттерны проектирования», т. к. не существует оптимальных решений на каждый случай из жизни. То, что было правильным в одном случае, например микросервисная архитектура, позволявшая трём командам писать код на разных языках для обеспечения разного уровня производительности, может стать проблемой, когда существует мегасервис, на который приходится 80% всей нагрузки и который обращается во множество других микросервисов для получения от них данных, подлежащих агрегации на его уровне.
Вам как архитектору придётся управлять, что называется «от противного», предлагая решение, которое должно работать правильно, при этом не имея возможности заблокировать неправильную реализацию. Как я уже писал в правиле о разумности ограничений, вас будут обходить и тащить реализацию «корявую», но быструю или «бизнес-обоснованную».
Упираться на этом этапе и доказывать свою правоту бессмысленно, вас просто перестанут спрашивать, и тогда вы потеряете возможность обрести необходимое могущество в будущем.
Тут наиболее правильной позицией будет представление правильного решения с точки зрения архитектуры, но в виде консультации. Дальше команда, как правило, начинает это решение ломать или пытаться обойти — все эти изменения вы запретить не сможете, поэтому мудрым будет сказать что-то вроде: «Вы можете не делать, как я спроектировал, воля ваша. Я вижу вот такие риски и проблемы в будущем, но я не настаиваю на такой реализации, делайте как считаете нужным».
Вам придётся набраться терпения и дождаться момента, когда кривая реализация станет камнем преткновения и источником проблем. Когда дело дойдёт до разборок, ваша изначально спроектированная архитектура станет козырем, и вы сможете, опираясь на неё, сказать: «Я изначально предлагал делать по-другому, но…»
Дальше необходимо привести список того, что меняло архитектуру и в итоге привело к отклонению от спроектированного решения и, как следствие, к проблемам.
Дальше необходимо привести список того, что меняло архитектуру и в итоге привело к отклонению от спроектированного решения и, как следствие, к проблемам.
Такое упражнение придётся проделать ни один раз, пока на очередном обсуждении вы или команда не предложит: «Не делать как обычно, а послушать архитектора». В этот момент вам и нужно будет взять власть, предложив нормальное решение. Не поддавайтесь иллюзиям — одного удачного кейса недостаточно, чтобы стать доверенным лицом в принятии решений.
Вам придётся и тут набраться терпения и предлагать решения раз за разом, пока в головах людей не сложится паттерн: не послушали архитектора — вышло плохо, послушали архитектора — и всё получилось.
Выработка паттерна требует:
- Слома старого шаблона;
- Формирование нового шаблона;
- Закрепление нового шаблона поведения.
Чтобы быть чуть более конкретным в числах, приведу пример из одной книги, в которой утверждалось, что для слома старой привычки требуется 22 дня непрерывных усилий, 22 дня на формирование новой, и 22 дня на закрепление нового шаблона.
Итого на изменение требуется 66 дней, переводя это на архитектуру вам потребуется 66 раз быть последовательным рационалистом, что правда нелегко, но награда может быть щедрой.
Не знаю, связана ли эта цифра с известным Приказом 66 из звездных войн, но после его исполнения Галактическая республика действительно круто поменялась, а власть перешла к серому кардиналу — дарту Сидиусу.
Приведу список критериев, на которые архитектору стоит обращать внимание при проектировании и указывать на них другим членам команды:
- Производительность
Наиболее быстро проявляющие себя ошибки в проектировании обнаруживаются именно здесь. Например, выбор СУБД, ориентированной на запись, при высокой нагрузке на чтение быстро проявит себя в виде падений сервиса и роста количества инфраструктуры. Хранение аналитических данных в виде файлов в S3 хранилище быстро обрастёт тяжёлой обёрткой для трансформации данных, и таких примеров можно привести ещё множество. - Организационная сложность
Проявляется не так явно и, как правило, вне цифрового мира показателей и графиков нагрузки, но порой куда болезненнее. Дробление системы на множество независимых сервисов, разрабатываемых разными командами на разных языках, в итоге приводит к тому, что команды начинают идти с разной скоростью и своими приоритетами. В момент, когда появляется задача, затрагивающая большое количество компонентов системы, собрать единый план реализации может превратиться в организационный ад. - Сетевая связанность
Редко учитываемый факт командами разработки, которые строят свои облачные решения в разных концах инфраструктуры, порой физически удалённых. Это сетевой трафик, который должен путешествовать между множеством средств защиты (firewall, интеграционные шлюзы и прочее), в каналах с разной пропускной способностью. При этом приложения должны выдерживать жёсткие KPI, которые, как правило, не учитывают этих сетевых походов, а накладываются только на конкретный сервис. - Стоимость изменений
Тут стоит сделать важную оговорку: архитектор не считает и не отвечает за деньги напрямую. Здесь имеется в виду время, которое потребуется на реализацию изменений, которое будет напрямую зависеть от сложности технического ландшафта, используемых технологий и организационной сложности. Например, если какое-то решение построено на вендорском ПО, изменения в которое вносит только вендор с релизным циклом раз в полгода, то стоимость ошибки проектирования составит полгода. Ровно столько пройдёт от реализации первого неправильного решения до исправления вендором архитектуры решения. - Безопасность решения
Последний в списке, но далеко не последний по значимости критерий. Как правило, вопросами безопасности должна заниматься служба ИБ, которая, по опыту, иногда этим реально занимается. Но в большинстве случаев она занимается профанацией этой деятельности, затягивая с согласованием, не выдавая списка требований или выдвигая оторванные от реальности требования, а порой просто бесконечно выясняя суть архитектурного решения. При этом службы ИБ ещё больше, чем архитекторов, любят обходить стороной. Выставить FTP в открытую сеть с персональными данными может казаться крайне быстрым и заманчивым вариантом, но в будущем такое решение может иметь крайне негативные последствия.
В заключение: архитектура — это элемент управления такой же, как и должностная инструкция, но куда более сложный и тонкий.