Как создать надежную архитектуру в гибком мире? Вот метод создания архитектуры, учитывающей постоянные изменения.
Когда-то, в начале жизненного цикла проекта, архитектура была «готова».
Это важный шаг, на котором исследуются все «возможности» (масштабируемость, доступность, наблюдаемость и т. д.).
Так что, учитывая современный динамичный мир и то, что заказчик может не увидеть ощутимой выгоды от (дорогостоящей) фазы архитектуры, как нам реализовать «гибкую архитектуру»?
Архитектура в гибком мире
Об Agile-архитектуре написано много, но я не думаю, что у нас есть общепринятая практика для этого.
Архитектура, сделанная хорошо и тщательно, сложна. Если вы мне не верите, я рекомендую Основы архитектуры программного обеспечения и Архитектура программного обеспечения: основные моменты. Кроме того, есть вся специфическая архитектура облачной инфраструктуры и архитектура DevOps.
Хорошая архитектура должна учитывать множество различных точек зрения (как технических, так и человеческих) и постоянно противопоставлять одну другую.
Аргумент MVP
Существует школа мысли, что в архитектуре нет необходимости, и разработчики могут создавать минимально жизнеспособный продукт (MVP).
Для простых решений это может быть ценным упражнением. Если все сделано правильно, MVP может дать много уроков, помогая определить, чего хотят клиенты. В этом смысле это форма прототипирования.
Однако любой рост от MVP потребует некоторой архитектуры.
Кроме того, если у вас есть клиент, который платит за решение, и вы предлагаете предоставить клиенту минимально жизнеспособный продукт, это может звучать так: минимум за те деньги, которые вы нам даете». Однако если вы говорите, что сначала создадите MVP, чтобы ускорить процесс сбора требований, а затем предоставите надежное решение, за которое они заплатили, это совсем другое предложение.
Как архитектор проекта, обеспечивающего MVP, вы должны помочь правильно определить его масштаб. Убедитесь, что MVP является одноразовым, или, что более типично, есть четкий момент, когда MVP ответил на вопросы, и есть структурированная эволюция в законченный продукт.
Архитектура все еще нуждается в доработке
В любом случае, кроме быстрого стартапа, в какой-то момент архитектуру все равно придется делать.
Часто откладывание его на потом приводит к дорогостоящему путешествию.
Реализация архитектурного замысла
В современном мире нет места для Big Up-Front Design (BUFD), и это хорошо. BUFD потратил миллионы долларов без явной ценности, и часто дизайн устарел, когда (или если) он был закончен.
Решением этой проблемы является разработка Архитектурного замысла.
Архитектурный замысел — это общая картина.
Учитывая потребности вашего проекта, клиента, решения или предприятия, какова окончательная архитектура, которая справляется со всеми «возможностями»? Какие возможные продукты могут помочь в достижении целей?
На первый взгляд это может звучать как BUFD, но то, что вы делаете, — это изложение долгосрочного архитектурного видения. Еще не все детали раскрыты. Это зависит от вашего конкретного решения, чтобы определить архитектурно значимые аспекты, которые могут потребовать дополнительной конкретизации.
Этой архитектуры достаточно, чтобы задать направление.
За исключением нескольких (и теперь редких) государственных ИТ-проектов, никто не может позволить себе внедрить полную архитектуру с самого начала.
Архитектурное намерение задает направление всей архитектуры. Однако архитектурное намерение может и будет меняться.
Как и в случае всех гибких или инкрементальных поставок, требования будут меняться. Изменения требований могут изменить направление, заданное архитектурным замыслом.
Кроме того, программа трансформации может занять несколько лет. К тому времени, когда вы реализуете некоторые аспекты архитектурного замысла, могут быть доступны другие технологии, чем когда вы начинали.
Но что насчет сейчас?
С архитектурным намерением, определяющим долгосрочное видение, построение в направлении этого видения будет постепенным.
Учитывая архитектурный замысел, какие аспекты в первую очередь соответствуют непосредственным требованиям?
Кроме того, с учетом текущих технических возможностей команды разработчиков, какую часть намерения необходимо сократить, чтобы избежать риска доставки?
Опять же, архитектура — это все об этих компромиссах. И это компромиссы, которые имеют коммерческие последствия, а не то, что архитектор делает в одиночку.
В отличие от Архитектурного замысла, Непосредственная архитектура конкретна. Существуют точные спецификации или политики в отношении того, что должно произойти.
Непосредственная архитектура для архитектурного замысла
Неудивительно, что шаги от Непосредственной Архитектуры до Архитектурного Замысла формируют вашу дорожную карту и определяют приращения продукта или выпуска.
В зависимости от того, насколько гибок проект, могут быть четко определены только следующие шаги в дорожной карте. Цель состоит в том, чтобы не делать слишком много BUFD; напрасные усилия при изменении требований.
Не оставляет ли это решение с самого начала лишенным необходимой архитектуры?
Нет. Как архитектор, вы все равно должны убедиться, что все необходимые «функции» присутствуют в Непосредственной архитектуре. Тем не менее, могут быть некоторые переговоры с клиентом для начальных приращений.
Вы также можете обнаружить, что объемы данных и количество пользователей изначально невелики, что позволяет использовать поэтапный подход для поддержки масштабируемости и параллелизма.
Что ты думаешь?
Вы пытались создать надежную архитектуру в гибком мире?
Считаете ли вы, что концепции «архитектурное намерение» и «немедленная архитектура» имеют для вас смысл?
