Сотрудничество с командами, управляющими рабочими нагрузками, и командами платформ.

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

Задачи непрерывной совместной работы

• Предоставьте ясность. Будьте доступны для уточнения спецификаций, чтобы команды реализации оставались разблокированы. Участвуйте в планировании итераций и групповых собраниях для решения потенциальных блокировщиков.

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

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

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

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

Используйте доказательство концепции (POC)

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

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

Управление техническим долгом

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

• Намеренно: долг берется намеренно, а не случайно. Быть преднамеренным помогает обеспечить краткосрочную гибкость без ущерба для долгосрочной жизнеспособности.
• Документировано: Отслеживание долга в бэклоге. Задокументированный технический долг количественно оценивает риски и затраты, предоставляя вам проверяемый реестр задолженностей. Используйте невыполненную работу для выравнивания исправлений с вехами плана, циклами бюджета и ограждениями платформы.
• Возвратный: используйте извлеченные уроки, собранные при взятии технического долга, чтобы создать тщательный, экономичный план для устранения этой проблемы в будущих итерациях.

Совместная работа с командами платформы

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

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

Руководство и обмен знаниями

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

Следующие шаги