你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
提供体系结构规范不是一次性任务。 架构师应在整个实现过程中与工作负荷团队联系。
持续协作任务
提供清晰度。 随时待命以阐明规格，确保实现团队不会遇到问题。 参与迭代计划和团队会议，以解决潜在的障碍。
关于实施顺序的建议。 架构师了解到，从设计到生产就绪产品的旅程是迭代的。 建议首先处理高风险组件或关键路径项。 此方法可帮助工作负荷团队尽早识别可行性问题，并将学习应用到工作负荷的其余部分。
设置实现评审检查点。 工作负荷团队应建立常规检查点，以便将实现与体系结构规范进行比较。 这种做法有助于确保根据规范实施设计，并且该规范符合预测的要求。 此反馈循环可以纠正设计或实现错误。
与利益干系人沟通。 架构师与利益干系人和业务有着既定的关系，并且对工作负荷有深入的了解。 因此，他们通常处于传递实施团队关注或协商要求更改的良好位置。
提出环境建议。 工作负荷设计通常超出了针对生产及其灾难恢复进行设计的范围。 生产只是工作负荷实现团队可能需要的许多环境之一。 架构师还可以帮助工作负荷团队在适当大小的预生产环境中工作。
使用概念验证（POC）
架构师在其设计中使用 POC 来决定工作负荷体系结构的设计规范。 这些 POC 还可以深入了解实际工作负荷实现的可行性。
风险： 常见的陷阱是将 POC 代码视为生产就绪。 POC 通常无需进行安全、日志记录或错误处理即可快速证明特定概念。 架构师必须明确 POC 代码是可释放的，不应复制粘贴到生产代码库。 请改用 POC 学习，然后使用已建立的工程标准编写生产代码。
管理技术债务
有时，为了达到最后期限或其他限制，团队可能会产生技术债务。 架构师的作用是确保债务是：
- 故意：债务是故意的，而不是意外的。
- 记录：债务在待办事项中进行跟踪。
- 可偿还：在未来迭代中，有一个经济高效的计划来解决它。
与平台团队协作
某些组织在工作负荷和平台团队之间分配职责，如 Azure 登陆区域所示。 对于将与平台团队合作以共同交付解决方案和价值的工作负载，请务必与这些团队协作。
建筑师应倡导 黄金路径：保护和自动使用平台资源的方法。 如果不与平台团队协作，设计可能会错过利用可用平台提供的产品/服务的成本，或者可能设计出违反平台授权约束的解决方案。
指导和知识共享
架构师的价值在补充团队技能时成倍增加。 使用代码评审、设计会话和“午餐和学习”来解释体系结构决策背后的 原因 。 这使实施团队能够做出符合整体愿景的决策。