你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
与工作负荷团队协作
交付体系结构规范不是一次性任务。 架构师应期望在整个实现过程中与工作负荷团队互动。
持续协作任务
提供清晰度。 架构师应随时可用，以明确任何交付的规范，以确保实现团队保持不受阻止。 为了解决潜在的阻碍，架构师应积极参与迭代规划练习和团队会议。
提出实现排序建议。 架构师了解到，从设计到生产就绪产品的旅程是迭代的。 他们可以建议首先实现应用程序的哪些部分。 此方法使工作负荷团队能够从该体验中学习，并应用他们获得的知识，使其适用于工作负荷的剩余部分。
设置实现评审检查点。 工作负荷团队应建立定期评审检查点，以便将实现与体系结构规范进行比较。 这种做法有助于确保根据规范实施设计，并且该规范符合预测的要求。 此反馈循环可以纠正任何设计或实现错误。
与利益干系人沟通。 架构师与利益干系人和业务有着既定的关系，并且对工作负荷有深入的了解。 因此，他们通常处于一个良好的位置，可以中继实施团队的关注或要求谈判更改的要求。
提出环境建议。 工作负荷设计通常超出了针对生产及其灾难恢复进行设计的范围。 生产只是工作负荷实现团队可能需要的许多环境之一。 架构师还可以帮助工作负荷团队在适当大小的预生产环境中工作。
使用概念证明（POC）。 架构师经常在其设计中使用 POC 来决定工作负荷体系结构的设计规范。 这些 POC 还可以深入了解实际工作负荷实现的可行性。 如果 POC 不存在，架构师应在实现团队开始开发之前创建一个。
与平台团队协作
某些组织在工作负荷团队和平台团队之间分配职责，例如在 Azure 登陆区域中建议。 对于将与平台团队合作以共同交付解决方案和价值的工作负载，请务必与这些团队协作。 如果不与平台团队协作，设计可能会错过利用可用平台提供的产品/服务的成本，或者可能设计出违反平台授权约束的解决方案。