Соотнесите интересы сторон с техническими требованиями
Когда речь заходит о разработке архитектуры программного обеспечения, в первую очередь мы представляем себе классические технические операции: разбиение системы на модули, определение интерфейсов, распределение ответственности, применение шаблонов и оптимизация производительности. Кроме этого архитектор должен учитывать ряд других аспектов, в том числе вопросы безопасности, удобства использования, простоты сопровождения, управления выпуском, выбора параметров развертывания и т. д. Но все перечисленные технические и процедурные аспекты должны быть соотнесены с потребностями заинтересованных сторон. Принять во внимание эти интересы при анализе требований — отличный способ обеспечить полноту спецификаций требований для разрабатываемого продукта.
У всех вовлеченных в проект сторон есть интересы, затрагивающие как процесс разработки программного обеспечения, принятый в организации, так и организацию в целом. Именно анализ этих интересов формирует итоговый набор приоритетов для архитектора. Можно сказать, что создание архитектуры — это процесс балансировки приоритетов в краткосрочной и долгосрочной перспективах в рамках имеющегося контекста.
Для примера возьмем инженерно-технический отдел организации, предоставляющей услуги по разработке программного обеспечения. Скорее всего, у этой организации существуют определенные приоритеты: соблюдение контрактных обязательств, получение дохода, поддержание хорошей репутации среди клиентов, снижение затрат и создание ценных технических активов. Эти бизнес-приоритеты преобразуются в приоритеты отдела: обеспечить функциональность, корректность и «атрибуты качества» разрабатываемого продукта, а также продуктивность команды разработки, устойчивость процесса разработки, возможность его аудита, адаптируемость и долговечность программных продуктов.
Работа архитектора состоит не в том, чтобы просто создать функциональный, качественный программный продукт для пользователей, а в том, чтобы сделать это с соблюдением баланса интересов других сторон — руководства компании (сокращение затрат), персонала, обслуживающего продукт (простота администрирования), будущих членов команды программистов (простота изучения и сопровождения), а также с учетом опыта, накопленного профессиональным сообществом архитекторов.
Архитектор может на короткое время сознательно сместить баланс в пользу одного из приоритетов, но в долгосрочной перспективе, чтобы работа была выполнена действительно хорошо, следует избегать каких-либо перекосов. При этом поддерживаемый баланс должен отвечать имеющемуся контексту с учетом таких факторов, как предполагаемая продолжительность жизненного цикла программного продукта, критичность продукта для организации, техническая и финансовая культура компании.
Говоря коротко, создание архитектуры программного продукта не ограничивается одними лишь техническими аспектами; в процессе работы необходимо также найти правильное соотношение технических требований и бизнес-требований всех заинтересованных сторон.
Биография автора приведена ранее.