第9部分。持续关注技术卓越性和良好的设计，以及……10.简单性
实际上，我发现这处于市场上几乎所有当代敏捷开发人员的理解和能力之上的水平。 如果他们理解这一点，他们通常会是建筑师。 对细节的关注度非常低，使大多数开发人员无法相信对一种好的设计模式的理解就足够了，而无需了解每种设计都特别适合一种情况而不是另一种情况的权衡取舍。 这对他们来说是一个危险的职位，因为反模式是模式选择不当或要求无法满足模式无法预期的结果。 此外，低级开发团队没有看到的是整体设计中的优化点，以允许并促进团队中代码或组件的重用。 在这里，解决方案架构师可以通过具有更高层次的视图来弥合理解上的差距，从而使他们可以在部署交付物时看到它们，并可以管理这些软件资产的重用，这成为解决方案构建块，并已添加到解决方案构建块中。企业资源库是解决方案连续性的一部分。 确实，跨团队进行重复工作非常容易，而错过了这一步骤。 毕竟，如果一个开发团队信任另一个开发团队来抵抗第一个开发团队发出的“拉动”信号，而第一个开发团队则交付自己的相关功能，并被客户或更糟的第二个团队信任来提供此功能。精打细算的主要罪恶之一就是阻止工作重复，因为它是浪费的直接形式。 除了产生必须交付以允许企业参与的架构功能之外，企业架构师不承担原则9的责任。 他们的简单性观点（原则10）是组合优化，它降低了组合复杂性，从而减少了涉及的开发团队为交付软件而进行的每组迭代所需的工作量，并获得了更大的收益。企业改变方向所需的精力。 请考虑以下两种情况。 开发团队生产的一块软件（例如，一项服务）实现了一个业务流程，该业务流程本身消耗了公司周围其他4个服务中的功能。 其他4个服务都相互双向链接，但不是第一个（即，对于4个内部服务，通过6个通道有12条通信链接）。 这里有5个服务，并且假设这4个内部服务之一更改了其服务合同。 负责此服务合同的开发团队将开发并发布新接口，这将断开与服务的所有其他连接（其他3个）。 然后，其他3个团队必须更改其对该服务合同的使用并相应地编码。 涉及的工作量很大。 这已经打破了一致性治理原则的对称性。…
