陷阱 #16 只是架构图

我们都看到了 从业者 拿出一张精心绘制的架构图，展示系统未来各个元素之间的关系。我们虔诚地凝视着这幅图，欣赏它的优雅。然后，我们着手创建一个只与架构图有表面关联的系统。.

为什么？所有构成 有用的架构 缺失：

• 表明需要做出哪些改变的差距
• 降低企业风险的控制措施
• 约束设计师、实施者、运营商和未来建筑师的规范
• 任何能够凸显未来生态系统如何提供比现在更好的价值的东西

这些精心设计的图表通常代表了整个生态系统的一部分。然而，这些图表往往充斥着为了支持实践者偏见而做出的任意设计选择。.

良好的架构支持在架构开发过程中做出明智的决策，并约束设计、实现和操作选择。架构图或许可以做到这一点。.

你不能用框框和线来治理

通常，基于图的交付方式会阻碍利益相关者、决策者和关键贡献者在开发过程中积累的丰富理解。之所以出现这种情况，是因为很少有图表能够代表多个关注点。当我们专注于这些图表时，我们就会隐性地避免复杂的权衡，而专注于单一的优化。.

伪装成架构的图表充斥着不合理的规范和控制。不合理之处在于规则本身‘独立存在’。这种图表脱离了上下文，指定了服务提供商、软件或运营地点。优秀的架构师看到这种情况，不得不忍住不去问“为什么？”

最佳实践是将规范明确地与目标、宗旨或其他要求联系起来，并将设计选择与规范联系起来。如果没有这种联系，我们如何评估设计选择与目标的契合度？

我们都听过这样的借口：‘但图表只是一个视图。’在我们的 EA 能力实践中，我们对此感到很困惑。如果 架构视图 维护突出关注点、需求、偏好、关系和分析的信息的存储库在哪里？你猜从业者的想法在哪里，同行评审和重用是不可能的。.

Conexiam 导航 使用解决方案开发手册（SDN）来积极支持变更和实施团队，并帮助项目组合经理控制变更计划并衡量价值。在每个 SDN 中，架构师都需要为实施者、所有者和项目组合经理确定必要的指导。.