实际上，我发现这处于市场上几乎所有当代敏捷开发人员的理解和能力之上的水平。 如果他们理解这一点，他们通常会是建筑师。 对细节的关注度非常低，使大多数开发人员无法相信对一种好的设计模式的理解就足够了，而无需了解每种设计都特别适合一种情况而不是另一种情况的权衡取舍。 这对他们来说是一个危险的职位，因为反模式是模式选择不当或要求无法满足模式无法预期的结果。
此外，低级开发团队没有看到的是整体设计中的优化点，以允许并促进团队中代码或组件的重用。 在这里，解决方案架构师可以通过具有更高层次的视图来弥合理解上的差距，从而使他们可以在部署交付物时看到它们，并可以管理这些软件资产的重用，这成为解决方案构建块，并已添加到解决方案构建块中。企业资源库是解决方案连续性的一部分。 确实，跨团队进行重复工作非常容易，而错过了这一步骤。 毕竟，如果一个开发团队信任另一个开发团队来抵抗第一个开发团队发出的“拉动”信号，而第一个开发团队则交付自己的相关功能，并被客户或更糟的第二个团队信任来提供此功能。精打细算的主要罪恶之一就是阻止工作重复，因为它是浪费的直接形式。
除了产生必须交付以允许企业参与的架构功能之外，企业架构师不承担原则9的责任。 他们的简单性观点（原则10）是组合优化，它降低了组合复杂性，从而减少了涉及的开发团队为交付软件而进行的每组迭代所需的工作量，并获得了更大的收益。企业改变方向所需的精力。
请考虑以下两种情况。
开发团队生产的一块软件（例如，一项服务）实现了一个业务流程，该业务流程本身消耗了公司周围其他4个服务中的功能。 其他4个服务都相互双向链接，但不是第一个（即，对于4个内部服务，通过6个通道有12条通信链接）。 这里有5个服务，并且假设这4个内部服务之一更改了其服务合同。 负责此服务合同的开发团队将开发并发布新接口，这将断开与服务的所有其他连接（其他3个）。 然后，其他3个团队必须更改其对该服务合同的使用并相应地编码。 涉及的工作量很大。 这已经打破了一致性治理原则的对称性。
企业架构师将研究涉及的功能，确定在任何过渡或目标体系结构中是否必需，并采取措施对此进行更改。 这可能包括使用SOA交付ESB体系结构模式，其数据体系结构与供应商无关，但能充分满足特定企业要求（简称基础规范数据模型或CDM），这是从基础数据体系结构转变而来的，包括通用的系统架构，行业架构以及最终的组织架构（从企业通用性到最一般到最具体）。 然后可以逐步将其推广到特定的数据和/或集成解决方案架构师，以实现该愿景。
解决方案架构师可以选择ESB平台，为要附加到ESB的每个服务创建规范化者的合同，交付CDM，还可以指定要集成的服务的特定消息传递格式和CDM之间的规范化转换。 所有开发团队都向其系统交付自己的规范化转换，并将其附加到ESB。 这意味着只需要支持到ESB的4条链接而不是6条，使得8条双向链接不是12条！
但是，真正的节省来自与适应性相关的非功能性需求。 如果发生上述情况，并且合同发生了变化，则涉及的开发团队只需更改与该服务的规范化器相关联的转换，就可以大大减少其他开发团队的工作量，这将达到零。 这是一个单一的团队，他们必须提供一个单一的一致性界面（已经在CDM一致性和治理流程周围创建了测试的接口），这将上述方案的总体开发工作从3个渠道减少到1个，与第一种方法相比，相当于节省了整个2个团队的开发时间。
此外，如果系统上有20个内部服务，每个内部服务相互依赖，则通信链接的数量可以达到380，而与ESB之间的通信数量仅为40，从而大大减少了工作量。
开发人员的权衡是引入标准化过程。 这不是浪费！ 必须确保完成“投资”以节省资金，从而提供直接的业务价值，包括利润的货币增加，以实现更大的前景，从而实现收益。 不提供并管理该投资，类似于不预先编写单元测试（因为预先进行单元测试是指以后要支付股息的投资）。
因此请注意，好的设计包括建筑！ 技术卓越包括建筑！ 不幸的是，世界上程序员比建筑师多得多。 因此，关于无架构敏捷的观点（与这些原则完全相反）似乎只是因为数字而在英国占了上风。 敏捷方法不会拯救您一个人！ 注意“内部利益相关者”🙂
