Согласование технической стратегии с бизнес-требованиями

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

Каждое решение формируется реальным давлением: бюджеты, сроки доставки, правила соответствия требованиям, ожидания производительности и обязательства на уровне обслуживания. Это не необязательные рекомендации. Это условия, которым должен соответствовать ваш дизайн.

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

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

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

Прослушивание: сбор запросов заинтересованных лиц

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

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

Рассмотрим этот распространенный сценарий. Бизнес-команда говорит: "Нам нужно 100% время безотказной работы". Сначала это кажется простым требованием. Тем не менее, возможно, они приравнивают высокий уровень доступности к высокому качеству или у них импульсивная реакция на недавний сбой, или следуют за тенденцией, принятой конкурентом, без надлежащего анализа.

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

Проба: понимание мотивации

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

• Является ли он движущим доходом или в первую очередь поддерживает бизнес?
• Влияет ли это на ключевую часть организации или решает нишевую проблему?
• Это вопрос, касающийся производственной проблемы?
• Это обусловлено конкуренцией или рыночными сдвигами?
• Требуется ли оно для соответствия требованиям?
• Является ли это частью более широкого стратегического направления?

Мотивация имеет значение, потому что два аналогичных запроса могут представлять очень разные намерения. Функция, необходимая для удовлетворения крайнего срока регулирования, требует другого архитектурного подхода, отличного от того, который предназначен для разблокировки новой возможности роста.

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

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

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

Прояснить: преобразование запросов в требования

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

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

• Какие потоки пользователей всегда должны быть доступны?
• Что происходит, если вторичный поток временно не работает?
• Какие функции влияют на доход?
• Что такое допустимые режимы снижения?

На этом шаге "100% бесперебойная работа" разбивается на требования уровня потока.

• Размещение заказов. Должен быть высокодоступен. Время простоя оказывает непосредственное влияние на доход.
• Просмотр каталога. Может временно ухудшаться без критического ущерба.
• Журнал заказов. Может терпеть плановое обслуживание.

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

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

Оценка: проверка реализации, ограничений и компромиссов

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

Продолжая работу с примером высокой доступности, выложите компромиссы, например:

• Стоимость: многорегионная активная архитектура удвоит расходы на инфраструктуру.
• Сложность проектирования: репликация состояния между регионами не является тривиальной.
• Безопасность и соответствие требованиям: в нескольких регионах возникают вопросы хранения данных.
• Оперативная работа: дежурства 24/7 и сложные процессы переключения на резервные мощности.

Это точка, когда каждый ответ неизбежно начинается с "это зависит". Оценка часто предоставляет несоответствия между тем, что требуется бизнесу и что является практическим. Это помогает бизнесу понять, что на самом деле означает "100% работоспособность". Вы можете обнаружить, что только оформление заказа оправдывает развертывание в нескольких регионах, тогда как каталог и история заказов — нет. Кроме того, вы можете выявить риски, такие как незрелые возможности команды, переоцененные преимущества или недооцененные затраты. Вы также можете выявить возможности применения альтернативных подходов, которые лучше балансирует затраты, сложность и надежность. Например, кэширование каталога в CDN может достичь этого баланса, если компромиссы подходят для этого потока.

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

Рекомендуется: предложить техническую стратегию

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

Ваша рекомендация должна быть задокументирована и охватывать следующие аспекты:

• Решение уточненных требований
• Отражение ограничений и компромиссов, определенных во время оценки
• Четко сообщайте заинтересованным сторонам об опциях и их последствиях.

Возвращаясь к примеру времени безотказной работы, рекомендация может выглядеть так:

"Для защиты доходов должна выполняться проверка в конфигурации с несколькими регионами active-active. Службы каталогов могут выполняться в одном регионе с репликами чтения для обеспечения устойчивости. Журнал заказов может оставаться в одном регионе в запланированные окна обслуживания. Этот подход будет соответствовать требованию непрерывности, избегая ненужных дублирований и затрат".

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

Ожидаемый результат

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

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

Хорошо разработанная функциональная спецификация на этом этапе должна включать:

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

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

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

Дальнейшие шаги

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