博客

作者：The Open Group
 

本篇博文是BiZZdesign管理顾问 Marc Lankhorst 系列访谈的第三篇，对架构，特别是 ArchiMate 语言如何提高敏捷方法的价值进行了简单探讨。
 

您认为ArchiMate建模语言可如何在组织中支持和利用敏捷实践以及如何支持交付敏捷 Enterprise Architecture (EA) 能力？
 

对于单个敏捷团队来说，这一点无关紧要。ArchiMate 模型可能会为他们提供一些上下文，但这些上下文不是他们自己创建的。然而，若要保持敏捷团队之间更高程度的一致性，EA 就至关重要了，主要表现在两个方面：
1) 确保您所创建的内容与企业战略和目标保持一致；
2) 协调不同的团队。例如，如果某个团队决定推迟某项特性的交付，那么这样做会对其它团队以及总体目标和结果造成什么影响？掌握全局和划分好整体优先级可帮助确保不同的团队和迭代 (sprint) 保持一致步调。
 

为未来制定详细的计划不现实，准时构建合适数量的架构才是关键，请记住，最小化可行产品理念也适用于架构产品。如果没有这种协调，就会很容易生成“敏捷孤岛”，最终也无法实现敏捷性。良好的架构可帮助您日后更轻松地进行变更。
 

敏捷方法的主要考虑事项和原则之一是支持不同的团队快速交付，同时确保适当的协调和统一。该方法的主要挑战之一是如果变更得太快，架构模型可能会过时。您认为我们该如何利用 ArchiMate 标准来解决这一问题？
 

要保持平衡很难。关键是要避免在前期构建太多架构；最好是前期少构建架构，然后在后期需要时（更确切地说在需要前）进行增建，例如为了协调进行增建。如果架构产品设计得太详细，可能很快就会过时。而且，时刻更新架构产品可能不值得，特别是在单个敏捷团队层面。
 

架构师需要专注于创建未来，因为他们创造的价值主要在未来实现，然而，清楚当下所拥有的也很重要。我渐渐发现，对当前状态架构的跟踪在某种程度上可自动进行，例如通过 CMDB 监控哪些应用出现在您的网络上。
 

在更高层面上，架构描述被保留并用于支持和协调团队。还需要切记敏捷方法的共享责任概念：架构师创建的架构并非只归其个人所有，而是由敏捷团队共同所有和演进。
 

大多数敏捷技术和工具在迭代、待办事项、用户故事方面与团队组织相关联，并需要团队之间展开大量动态交互，因此动态概念正逐渐超越架构描述。

ArchiMate 作为建模符号将如何支持敏捷方法呢？

根据 The Open Group 标准 TOGAF® 标准的描述，EA 作为一项规范其主要原则之一是基于一套能力构架持续迭代，并连接分区和战略架构。在 Scaled Agile Framework (SAFe) 等敏捷方法中，这种专注于能力的迭代架构开发概念在该框架的较高层面上也至关重要。SAFe 的许多概念都可轻松映射至 ArchiMate 语言，这一点我在相关博客中解释过：https://bizzdesign.com/blog/using-archimate-in-an-agile-context/。
 

提高企业敏捷性的方法之一是提高这些能力的独立性，在这些能力之间提供明确定义的接口，从而实现更轻松的本地化，加速变更。
 

敏捷方法的另一个重要特点是强大的自下而上治理，能够将敏捷团队的想法、改进和创新反馈回架构，甚至是您的战略。实施治理不应仅是一个自上而下的活动，还应能够对架构进行现状检查，利用团队反馈调整并改进架构。
 

简言之，我认为架构，特别是 ArchiMate 语言能够帮助提高敏捷方法的价值，我们的许多客户已经用实际行动证明了这一点。