與工作負載小組共同作業
提供架構規格不是一次性工作。 架構設計人員應該期望在整個實作中與工作負載小組互動。
持續共同作業工作
提供清晰性。 架構設計人員應隨時可供使用，以提供任何交付規格的清晰性，以確保實作小組仍保持不受封鎖。 為了解決潛在的阻礙，架構設計人員應該積极參與反覆項目規劃練習和小組會議。
提出實作排序建議。 架構設計人員瞭解從設計到生產就緒產品的旅程是反覆的。 他們可以建議先實作應用程式的哪些部分。 此方法可讓工作負載小組從該體驗中學習，並將他們獲得的知識套用至工作負載的其餘部分。
設定實作檢閱檢查點。 工作負載小組應該建立定期檢閱檢查點，以便比較實作與架構規格。 這種做法有助於確保根據規格實作設計，且該規格符合預測的需求。 此意見反應迴圈可以修正任何設計或實作錯誤。
與項目關係人溝通。 架構設計人員與項目關係人和業務建立了關係，並且對工作負載有深入的瞭解。 因此，他們通常處於轉送實作小組考慮或要求交涉需求變更的良好位置。
提出環境建議。 工作負載設計通常延伸到生產環境及其災害復原的設計之外。 生產只是工作負載實作小組可能需要的許多環境之一。 架構設計人員也可以協助工作負載小組在適當調整生產前環境的大小。
使用概念證明（POC）。 架構設計人員經常在其設計中使用POC，以決定工作負載架構的設計規格。 這些 POC 也可以提供實際工作負載實作可行性的深入解析。 如果 POC 不存在，架構設計人員應該先建立 POC，再讓實作小組開始開發。
與平臺小組共同作業
某些組織會分割工作負載小組與平臺小組之間的責任，例如在 Azure 登陸區域中建議。 對於將與平臺小組合作以共同提供解決方案和價值的工作負載，請務必與這些小組共同作業。 如果您未與平臺小組共同作業，您的設計可能會錯過利用可用平臺提供的供應專案的成本，或設計違反平臺授權工作負載限制的解決方案。