Изначальный текст из которого родился доклад на archdays recap 22

В чем истинная ценность архитектуры и зачем её улучшать? 5 лет назад, если бы меня спросили, зачем нужна продуманная архитектура приложения в компании - я бы ответил, что-то вроде: • Для удешевления разработки • Для контроля изменений • Для гибкости к внешним изменениям • Для повышения прозрачности • Для решение еще какой-то инженерной проблемы

И эти все ответы имеют право на существование, но вот только истинная ценность архитектуры далеко не в этом. Мое мнение (и не только мое), что архитектура приложения начинается с постановки бизнес цели компании. Глобальной цели, той к которой бизнес будет плыть ближайшие N-цать лет. В этот момент формируется некоторое видение того, с чем придется плыть, куда придется нырнуть, что придется выловить и т.д. По сути широкими мазками описывается жизненный цикл приложения в компании до, во время и после достижения поставленной бизнес цели.

Все немного хуже, когда такая цель – это тупо бабки. В этом случае цель не достижима, ибо она будет всегда больше-выше-сильнее, но всегда таже самая.

Но имхо во всех бизнесах на определенных уровнях зрелости появляется другая цель. Более важная. И деньги всего лишь средство её достижения. Вот в этот период расцвета компании архитектура проявляется в полный рост. Примером такой цели могут служить такие вещи как: • Создание лучших условий при пользовании вашим продуктом для людей с ограниченными возможностями • Разработка собственных компонентных-софтверных и других решений для обеспечения независимости • Стать первой компанией предоставляющей коммерческие перевозки на Марс
и тд

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

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

Мы иногда забываем, что мы все люди. А людям свойственно ошибаться. И архитектура, которую мы проектируем, увы, но тоже может быть не правильной, ошибочной или избыточной, или просто не нужной. ИТ отдел часто приходит к бизнесу и говорит – нам нужно 100500 тысяч долларов на внедрение новой супер вундервафли. Ибо она решит все наши (ИТ отдела) проблемы. Бизнесу естественно глубоко плевать и возникает ризонный вопрос – нафига оно нам надо? И этот ответ закрывается зачастую расчетами по уменьшению ттм, по повышению производительности, по уменьшению времени простоя при сбоях и т.д. и т.п. А по факту архитектура достижения глобальной цели претерпевает значительное отклонение в угоду насущных (или надуманных) проблем ИТ отдела. И чем компания имеет больший ИТ отдел, который даже иногда отпочковывается в отдельную ИТ компанию. Тем это отклонение может стать значительнее.

В моем мире розовых поняшек конечно бизнес знает куда идет, а архитектор его верный соратник и брат. Но в реальности конечно это не так. Поэтому появились такие веянья как инкрементально-итерационный подход, эволюционная архитектура, одно изменение за раз и прочие-прочие полезные штуки. В общем-то все они направлены на достижения всего лишь одной задачи – максимально часто корректироваться с бизнес требованиями и не ломать все сразу. Благо? Благо. Наверное. Но по хорошему, если ваша эволюционная архитектура не имеет горизонта планирования и собственного развития хотя бы на пару лет вперед – вы гребете на песке, веслами в разную сторону со слепым рулевым. Устойчивость к изменениям и самосовершенствование достигается только путем закладывания правильных движений на длинной дистанции. И чтоб их совершать, должно быть видение и цель. И вот она истинная ценность архитектуры – отражение движения к цели. Чем ближе мы к цели, тем наша архитектура больше её отражает. Чем мы дальше или если у нас её нет, тем в архитектуре больше всякого технически интересного, сложного и не нужного барахла. Честно говоря, я хотел бы это понимать до начала распила монолита, хоть само решение о распиле было коллегиальным и вроде технически обоснованным. Кажется решать нужно было совсем другие проблемы =) Ну задним умом все крепки.

Инженеры те еще мясники, им дай только что-нибудь отпилить По сути, когда весь мир заболел микросервисами, узкими доменными областями, контейнерами и вот этим вот всем. Кровожадность инженеров поднялась на новый уровень. Все что нужно и не нужно, надо распилить, раздолбать, разнести по подам и бесконечно скейлить и деплоить. Если же серьезно говорить, то идея работы приложения в контейнере в облаках в виде маленьких доменных областей - крута и полезна только тогда, когда ваше приложение было спроектировано таковым с самого начала, а ваша инфраструктура к этому готова (включая инженеров). В реальности же все как с graphql - тащим туда где надо и не надо, или пилим то, что не нужно распилить и героически преодолеваем самим же себе созданные трудности. Зато нам всем по кругу весело и есть о чем на конференциях рассказывать. =)

Порою нужно принять и простить. И переписать. Вещь, которую я понимал еще тогда, но смог наверное закрепить и доказать себе уже сейчас на 100%. Порою (и это далеко не редкий случай) нужно остановиться и написать заново. Так как требуется в данный момент времени, на технологиях, которые есть в данный момент времени, заложить прочности на следующий виток жизни приложения и отпустить. Да. Часто в историях где фигурирует распил монолита мы пытаемся себя обманывать тем, что туда и движемся, но типа маленькими шажками. Кто-то наверное доходит. Но на моей практике получаются франкентштейны, которых допинывают уже из соображений чувства долга и вмененной обязанности. А сколько на этом деле погорело инициаторов =)) Короче ваша архитектура устареет еще раньше, чем вы её успеете внедрить. А с распилом эта дистанция всегда x2, если не больше. Проще, иногда, договориться, сесть и пересоздать все заново. А если не получится договориться, так может цели бизнеса и ИТ отдела тут совсем не пересекаются и мы ничего полезного для компании и приложения не делаем на самом деле?

Архитектор в чем-то бизнес психолог. И большинство решений должны вытекать из общения с бизнесом, а не из техники. Из моих слов выше можно сделать вывод, что чтобы что-то нормальное спроектировать и выразить в хорошей архитектуре нужно чуть ли не жить вместе с акционерами и генеральными директорами под одной крышей. По моему личному мнению, идеальный архитектор - это человек на уровне топ. менеджемента, который в курсе всех дел, движений и планов компании. Вероятно он выполняет роль системного и бизнес аналитика, а также тренера для работы с остальными представителями директората, чтобы правильно формулировать и понимать цели, которые уже будут спущены вниз в разработку. Наверняка, такая схема хорошо себя показывает в каких-то компаниях. Но в моей жизни все не так =) • Хорошо, если архитектор может сходить и со всеми пообщаться и выяснить требования. • Хорошо, если ему их расскажут. • Хорошо, если те с кем он пообщался на самом деле лпр и действительно понимают чего хотят.

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

Архитектура рождается во время формирования цели, а потом находит свое отражение в срезах движения к достижению этой цели.

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