与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统的工作一样，并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是，敏捷专家的架构方式与传统主义者的方式略有不同。本文讨论以下问题：

1. 迈向敏捷架构
   
2. 整个生命周期中的架构
   
3. 谁负责架构？
   
4. 拥有“架构所有者”的角色
   
5. 大规模的敏捷架构
   
6. 根据需求建立您的架构
   
7. 为您的架构建模
   
8. 考虑几种选择
   
9. 记住企业约束
   
10. 旅行灯
    
11. 用工作代码证明你的架构
    
12. 沟通您的架构
    
13. 想想未来，等待行动（推迟承诺）
    
14. 采取多视图方法
    
15. 这是如何运作的？
    
16. 解决敏捷和架构周围的神话
    

1.迈向敏捷架构

体系结构提供了构建系统的基础，体系结构模型定义了体系结构所基于的愿景。架构的范围可以是单个应用程序，应用程序系列，组织，或许多组织共享的Internet等基础架构。无论范围如何，我的经验是您可以采用敏捷的架构建模，开发和发展方法。

以下是一些让您思考的想法：

• 架构没什么特别的。异端你说！绝对不。敏捷建模的谦逊价值表明每个人对项目都有同等的价值，因此任何担任架构师和他们努力的人都同样重要，但不会比其他人的努力更重要。是的，优秀的架构师拥有适合手头任务的专业技能，应具备有效应用这些技能的经验。然而，完全相同的事情可以说是优秀的开发人员，优秀的教练，优秀的高级管理人员等等。谦虚是您架构工作的重要成功因素，因为您需要避免象牙塔式架构的发展并避免您的队友的敌意。架构师的角色对大多数项目都是有效的，它不应该是由基座上的某个人完成的角色。
  
• 你应该提防象牙塔式架构。象牙塔式架构通常由架构师或架构团队开发，与项目团队的日常开发活动相对隔离。强大的架构专家会开发并开发一个或多个模型描述了团队中的仆从为架构师建立的最佳体系结构。象牙塔架构通常是美丽的东西，通常有很多花哨的图表和精彩的视觉陈述，宣称它们是你的救赎。理论上，这通常是您的架构师的工作基础，象牙塔式架构完美地运作。然而，经验表明象牙塔架构存在重大问题。首先，“minion开发者”不太可能接受这种架构，因为他们在开发过程中没有发言权。其次，象牙塔式架构通常是未经证实的，象牙塔式架构师很少会弄脏他们编写代码的手，因此在您知道他们实际通过技术原型提供的具体反馈之前，您的项目将面临重大风险。第三，如果架构师除了模型之外什么也不做，因为你无法思考系统所需的一切，象牙塔架构将是不完整的。第四，象牙塔式架构促进了软件的过度建设，因为它们通常反映了任何系统所需的每个功能。架构师曾经参与其中，而不仅仅是您的系统实际需要的功能。
  
• 每个系统都有一个架构。但是，它可能不一定具有描述该架构的架构模型。例如，一个小团队采用XP方法在同一个房间里一起工作可能没有必要对他们的系统架构进行建模，因为团队中的每个人都非常了解模型并不能为他们提供足够的价值。或者，如果存在架构模型，则通常会有一些简单的旧白板（POW）草图可能由定义的项目隐喻支持。这是因为XP的通信方面，包括结对编程和集体所有权，否定了需要在整个项目中开发和维护的架构模型的需要。其他团队 - 不遵循XP的团队，更大的团队，人员不在同一地点的团队 - 将发现他们的环境中固有的更大的沟通挑战要求他们超越口碑架构。这些团队将选择创建架构模型，以便为开发人员提供有关如何构建软件的指导。从根本上说，您执行体系结构建模的原因是为了解决开发团队成员无法实现共同愿景的风险。
  
• 架构规模敏捷。传统技术也是如此。为项目制定可行且可接受的架构策略对于您的成功至关重要，尤其是在敏捷团队大规模发现的复杂情况下。扩展问题包括团队规模，法规遵从性，分布式团队，技术复杂性等（有关详细信息，请参阅软件开发上下文框架（SDCF））。一种有效的体系结构方法使您能够解决这些扩展问题。
  

2.整个生命周期的架构

图1描绘了敏捷模型驱动开发（AMDD）的生命周期。在“迭代0”（Disciplined Agile Delivery（DAD）中的初始阶段），您需要使项目井井有条并朝着正确的方向前进。这项工作的一部分是初步要求设想和架构设想，以便您能够回答有关项目的范围，成本，进度和技术策略的关键问题。从架构的角度来看，在迭代0期间，目标是确定您的团队的潜在技术方向以及您可能面临的任何技术风险（应通过代码证明风险来解决）。此时您不需要详细的架构规范，事实上在软件开发项目开始时创建这样的规范是一个非常大的风险。相反，在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划，在实时（JIT）基础上识别细节。最终的结果是，体系结构随着时间的推移逐渐出现，最初由于更需要设置项目的基础而更快，但是随着时间的推移仍在不断发展，以反映对开发团队的更多理解和了解。这遵循小增量中的实践模型并降低项目的技术风险 - 您始终拥有一个坚实且经过验证的基础，可以从中工作。换句话说，你想要考虑未来，但等待采取行动。

图1.软件项目的敏捷模型驱动开发（AMDD）生命周期。

图2描述了Disciplined Agile Delivery（DAD）工具包描述的敏捷/基本生命周期。DAD工具包具有本文中描述的所有体系结构策略.DAD是一种混合体，它采用来自各种来源的策略，包括敏捷建模，Scrum，XP，敏捷数据等等。实际上，DAD在处理方面做了“繁重的工作”，因为它捕获了来自这些不同方法的想法如何组合在一起。因为DAD不是规定性的，所以它支持几个生命周期。图2的生命周期是DAD基于Scrum或“基本”的敏捷交付生命周期，但它也支持精益/看板类型的生命周期和持续交付生命周期。我们的想法是，您的团队应该采用对您所面临的情况最有意义的生命周期。

图2. DAD Agile生命周期（单击以展开）。

这种轻量级初始体系结构建模方法的替代方法是尝试在实现开始之前完全定义您的体系结构。这种极端通常被称为预先设计（BDUF）。这种方法背后的动机通常是项目管理不希望任何人前进，直到就方法或“一个数据真相”达成共识。不幸的是，这种方法通常导致没有人向前推进很长一段时间，象牙塔式架构往往在实践中证明是脆弱的，这种架构对于你实际需要的东西来说是过度的，和/或开发子团队在他们的拥有，因为他们不能等待架构师完成他们的工作。这种方法通常是所涉人员的一种思维方式的结果，是瀑布式软件开发时代（20世纪70年代和80年代，当今许多管理人员都是软件开发人员）的遗留思维过程。现实情况是，架构的发展非常艰难，这是您成功的关键，也是您从一开始就无法做到的。进化（迭代和增量）方法通过一次开发一次，并且只在您需要它时，解决了架构不充分或不适当的风险。

3.谁对架构负责？

这个问题比你想象的要复杂得多。答案很简单，适用于小型敏捷团队（绝大多数），团队中的每个人都负责架构。实践模型与其他人告诉你，你真的不想独自工作，坦率地说，架构是非常重要的，无论他们多么聪明，都不能留在一个人的手中，因此架构应该是一个团队的努力。在一个小型项目团队中，比如十五人或更少，我更愿意包括所有开发人员，因为它允许所有参与者在体系结构中发表意见。这增加了每个人对体系结构的理解和接受，因为他们一起工作一个团队。当架构证明不足时，它也增加了开发人员愿意改变架构方面的机会，也许它不像你最初想象的那样扩展，因为它是集团的架构而不仅仅是他们的架构。当一个人开发某些东西时，它就变成了“他们的宝贝”而且没有人喜欢听到他们的宝宝是丑陋的 - 当你发现他们的架构有问题时，他们可能会抵制任何批评。当整个团队开发一个架构时，人们通常更愿意重新考虑他们的方法，因为这是团队问题，而不是个人问题。

但是，“每个人都拥有架构”战略存在两个基本问题：

• 有时人们不同意。当团队未达成一致时，此策略可能会大幅崩溃，因此您需要具有架构所有者角色的人员来促进协议。
  
• 它不会扩展。当您的团队规模较大或地理位置分散时，在软件开发上下文框架（SDCF）中调出的八个缩放因子中的两个，您将组织您的团队成为一个子团队。在这种情况下，大规模的架构需要协调机构。
  

4.拥有“架构所有者”

对于任何相当复杂的系统，您需要花一些时间来构建它。您将做一些前期架构设想，让您开始朝着正确的方向前进，然后架构将需要从那里发展。许多敏捷团队发现他们需要扮演“架构所有者”角色的人，有时称为敏捷解决方案架构师。这个人通常是团队中技术最有经验的人，负责促进架构建模和演变工作。就像Scrum的产品所有者角色负责团队的要求一样，架构所有者负责团队的架构。架构所有者是Disciplined Agile（DA）工具包中的主要角色之一。

架构所有者不同于架构师的传统角色。在过去，架构师通常会成为架构的主要创造者，并且是少数参与其中的人之一。他们经常开发架构，然后“开发”它，或者更准确地强制它开发团队。架构所有者与团队协作以开发和发展架构。虽然在架构方面他们是最终决策权的人，但这些决策应该与团队以协作的方式进行。有效的架构所有者是在组织正在使用的技术方面经验丰富的开发人员，并且能够使用架构峰值来探索新策略。他们还应该对业务领域有很好的理解，并具备将架构传达给开发人员和其他项目利益相关者的必要技能。

5.规模敏捷架构

在大型敏捷团队，地理位置分散的敏捷团队或企业范围的架构工作中，您将需要架构所有者团队或企业架构团队（在敏捷建模中，我最初将其称为核心架构团队，这是我从未真正喜欢过的术语）。大型敏捷团队通常被组织成较小的子团队，如图3所示。每个子团队的架构所有者都是架构所有者团队的成员，这有助于增加每个子团队理解并遵循整体架构的机会。以及增加整体架构策略满足整体解决方案的全部需求的可能性。将有一个整体的首席架构所有者，这可能是一个轮流角色，负责促进团队。

图3.大规模的敏捷团队被组织成子团队的集合。

大规模组织敏捷团队有四种基本策略：

• 架构驱动的方法。使用此策略，您可以围绕架构中调出的子系统/组件组织子团队。当您的架构具有高质量（松散耦合且高度内聚）并且在子团队真正开始之前已经识别出子系统的接口时，这种策略很有效（接口会随着时间的推移而发展，但您希望获得良好的开端）在他们最初）。该策略面临的挑战是，它需要以反映架构的方式捕获您的需求。例如，如果您的体系结构基于大型业务域组件，那么一个需求应尽可能专注于单个业务域。如果您的体系结构基于技术层 - 例如具有用户界面（UI），业务和数据层的3层体系结构 - 那么如果可能，需求应该集中在单个层上。
  
• 特征驱动的方法。通过这种策略，每个子团队一次实现一个功能，这个功能对于利益相关者来说是一个有意义的功能块。我会将这种策略应用于架构展示了大量耦合的情况，并且您可以使用复杂的开发实践。这种方法的挑战在于子团队通常需要访问各种源代码来实现该功能，从而冒着与其他子团队发生冲突的风险。因此，这些团队进行了复杂的变更管理，持续集成，甚至可能是并行的独立测试策略（仅举几例）。
  
• 开源方法。使用此策略，一个或多个子系统/组件以开源方式开发，即使它是针对单个组织（这称为内部开源）。此策略通常用于许多团队广泛重用的子系统/组件，例如安全框架，并且必须快速发展以满足访问/使用它们的其他系统的不断变化的需求。此策略要求您采用支持开源方法的工具和流程。
  
• 其组合。大多数敏捷团队将适当地结合前三种策略。
  

图4描绘了大规模敏捷项目的体系结构活动过程。您通常会看到在大型项目（通常称为程序），地理位置分散的项目，复杂（域或技术）项目或企业级（通常支持敏捷企业架构）上采用这种方法。这种方法有四个重要方面：

• 设想初始架构。最小的架构所有者团队负责初始架构设想，然后将其带到子团队以获得反馈和后续演变。对于大型项目/项目，通常还有其他敏捷团队成员参与此初始建模工作，包括产品所有者甚至是关键项目利益相关者。预计工作的架构可以持续数天，对于非常大或复杂的项目，可以持续数周。对于企业架构工作，企业架构团队通常会在项目初始建模工作中包括项目级应用程序/解决方案架构师，并且通常包括执行利益相
  
• 与开发团队合作。在大型项目/程序中，如图3所示，架构所有者团队的成员将在项目的各个子团队中扮演积极的角色，将架构传递给子团队并与他们合作以通过具体的方式证明部分架构实验。对于企业架构工作，企业架构师将最低限度地充当顾问，他们的专业知识是企业架构，但更好的是他们将成为关键项目团队的活跃成员，承担架构所有者在这些团队中的角色。由于敏捷开发的协作性质，架构所有者只需简单地进行初始架构设想，或者通过偶尔审查他们的工作来“支持”项目团队，但他们必须“卷起袖子”并成为活跃成员项目团队。这将有助于他们避免创建“象牙塔式架构”，这在纸上听起来不错但在现实世界中证明是不切实际的。它还有助于增加项目团队实际利用架构的机会。
  
• 将架构传达给架构利益相关者。对于项目团队，架构利益相关者包括与敏捷交付团队，关键项目利益相关者以及开发团队其他成员合作的产品所有者。这些人需要了解架构愿景，已经取得的权衡以及实施架构的当前状态。
  
• 更新架构作品。架构所有者团队将发现他们需要偶尔聚集在一起，随着项目的进展改进架构，协商架构的更改并根据需要更新架构模型（如果有的话）。这些会议将在项目开始时经常举行，随着架构的巩固，需要越来越少。对于可能不是核心架构团队成员的开发子团队成员来说，参加一些会议以提供信息，或许他们参与了一些技术原型设计并与调查结果分享，这将是常见的。最好的会议很短，通常不超过一个小时，并经常站在白板周围 - 每个人都应该为会议做好准备，愿意出席和讨论他们的问题，以及作为一个团队一起工作。很快得出决议。
  

图4.大规模的敏捷架构流程

6.需求驱动的架构

您的架构必须基于要求，否则您就是黑客攻击，就这么简单。在识别架构需求时，主动利益相关者参与的实践对您的成功至关重要 - 请记住，需求来自项目利益相关者，而不是开发人员。技术架构要求的良好来源将包括您的用户及其直接管理，因为他们通常会对技术要求和约束有所了解。操作人员肯定会对您的部署体系结构有所要求。面向业务的需求的最佳来源正是您期望的 - 您的用户，他们的经理。您组织内的高级管理人员将获得可能导致系统潜在变更案例的见解。

正如您所期望的那样，实践应用正确的工件和并行创建多个模型适用于您的架构需求工作。当您处理架构的技术方面时，您将希望基于技术要求，约束和可能的更改案例。同样，当您处理体系结构的业务方面，可能识别软件子系统或业务组件时，您可能需要关注描述关键使用要求的基本用例或用户故事，以及可能适用于您的系统的关键业务规则。

架构团队（或架构所有者的小型项目）将犯的一个常见错误是忽略现有的和相关的工件，例如描述组织现有技术基础架构的网络或部署图，企业级业务模型（用例模型，流程）图表，工作流程图，公司业务规则等），或您的系统应符合的公司部署标准（适用于工作站，分支机构等）。是的，现有工件可能已过时或根本不适用于您的工作，但您至少应该努力检查它们并尽可能利用现有工作。与合适的人进行一些阅读或讨论可能会为您节省大量精力。换句话说，不要忘记尽可能重用现有的工件。

理解架构建模的一个重要概念是，尽管它通常在项目的早期发生，但它永远不会首先出现。从根本上说，您总是会花时间确定一些要求。其他任何东西都是黑客攻击，黑客肯定不敏捷。

7.建模你的架构

架构建模的主要目标应该是就您打算如何构建系统达成共识或理解。换句话说，你将建模以理解。我的经验是，99.999％的软件项目团队需要花一些时间来建模他们系统的架构，即使是依赖于隐喻来指导他们的开发工作的Scrum / XP团队也是如此。虽然你的XP团队正在识别你的系统的比喻，你和你的队友在开发你的初始版本时会想到好几周，但你经常会画出你认为你的系统如何工作的草图。在AM的练习放弃临时模型之后，您可能不会保留这些草图，这通常是因为它们是无法解决的想法，或者仅仅是因为您正在建模以了解问题，所以一旦您这样做，图表就不再对您有价值了。话虽如此，XP团队开发架构模型并没有错。这些模型可能就像你在公众可见的白板上留下的草图一样简单，因为虽然隐喻可以是非常有效的东西，但架构模型通常会提供团队所需的更多细节。正如您所期望的，Disciplined Agile Delivery（DAD）团队也将进行一些架构建模。

您如何以敏捷的方式为您的架构建模？我通常会努力创建一个或多个导航图，图表显示系统“景观”的概述。就像路线图概述了城镇的组织一样，您的导航图概述了系统的组织结构。导航图是系统架构视图的实例。当您阅读有关架构建模的书籍和论文时，作者提出的一个共同主题是需要各种架构观点，每位作者都会展示他或她自己的关键视图集合，您需要考虑这些观点。我的经验是，没有一套架构视图适合每个项目，而项目的性质将有助于定义您应该考虑创建的视图类型。这意味着您创建的导航图类型取决于您正在构建的系统的性质。这在概念上与AM的实践一致应用正确的工件，它告诉您应该使用正确的建模技术来完成手头的任务。例如，使用基于J2EE的技术构建复杂业务应用程序的团队可能会发现UML组件图和工作流图适合用作体系结构导航图。但是，构建企业数据仓库的团队可能倾向于使用基于其体系结构的数据模型和UML部署图。不同的项目，不同的架构视图，因此不同类型的导航图。有趣的是，两个项目都需要两个导航图，符合多模型原则。您需要灵活处理您的方法，因为一种尺寸并不适合所有情况。

组织将犯的一个常见错误是将其架构工作建立在其组织结构上。例如，具有强大数据组的组织可能希望将数据模型作为其体系结构的主要工件，而不管系统的实际性质如何。当你有锤子专家时，每个问题看起来都像钉子一样。当您使用新技术或尝试开发组织几乎没有经验的新系统时，这个问题非常普遍 - 过去运行良好的组织结构在您的新环境中可能不再适合您。有关架构和组织结构的含义的更多信息，请参阅Conway定律的组织模式。

要创建导航图，建模工作的主要驱动力应该是假设简单。创建简单内容的做法表明您应该努力识别可能的最简单的体系结构方法 - 您的体系结构越复杂，个体开发人员不会理解它的可能性就越大，错误和崩溃的机会就越大。此外，您的架构模型应包含正确级别的信息，显示系统的各个方面如何协同工作，而不是细节（这就是设计的全部内容）遵循实践描述模型简单。您还应该使用最简单的工具来完成这项工作，很多时候，您需要使用白板草图来模拟架构的关键方面。绘图工具可以使用CASE工具。普通旧白板（POW）可以使用绘图工具。当纸张和便利贴可以使用时，请勿使用POW。

重要的一点是，当您的所有通信都是面对面的时，导航图通常足以描述您的架构。如果不是这种情况，当您的架构所有者无法与开发人员密切合作时（可能某些开发人员位于远程位置），那么您需要使用文档补充图表。

当您进行架构建模时，您应该考虑利用可用的丰富架构模式，但您应该以有效的方式进行。“模式系统：面向模式的软件体系结构”这本书是开始学习常见体系结构模式的好地方，例如图层，管道和过滤器，代理，模型 - 视图 - 控制器和Blackboard。与分析和设计模式一样，应该按照惯例轻轻地应用模式 - 只有在明确需要时才将它们引入您的架构中。在此之前，如果您怀疑架构模式可能是合适的，那么您可能认为您将拥有需要代理的多个关键服务来源，然后对您的架构进行建模，以便在实际情况出现时应用此模式。请记住，您正在逐步开发系统，遵循小增量中的练习模型，并且您不需要在第一天就建立正确的体系结构（即使您愿意，也无法实现此目标）。

您应该认识到，您的架构模型将揭示您的系统对其他系统的依赖性或它们对您的依赖性。例如，您的系统可以通过Internet与信用卡处理服务交互，从遗留关系数据库访问数据，或为另一个内部应用程序生成XML数据结构。网络图和UML部署图对于识别这些依赖性非常有用，面向过程的模型（如工作流程图，UML活动图和数据流图）也非常有用。这意味着这些依赖关系表明可能需要遵循这样的做法：在您的团队与您共享依赖关系的系统的所有者之间正式化合同模型。理想情况下，许多这些模型已经到位，信用卡处理器可能具有您必须遵循的严格定义的协议，并且遗留数据库可能具有为其定义的物理数据模型，尽管诸如XML数据结构之类的新功能将需要足够的定义。有时，如果没有准确的文档，您需要对旧系统的现有接口进行分析，有时需要设计新的接口。在这两种情况下，都需要由您的团队，其他团队或合适的联合开发相应的合同模型。

您应该如何组织架构建模工作？在项目开始时，我将典型地将架构团队聚集在一个单独的房间中进行初步构想。理想情况下，这个会议将持续不超过几个小时，但在一些较大的项目上，它可能持续几天甚至几周（我会认真地质疑任何超过两周的努力）。与往常一样，建模会话越长，由于缺乏反馈而偏离航线的可能性就越大。这个建模会议的目标是就我们正在建立的系统的格局达成初步协议，或许不是达成共识，而是足够的协议，因此我们可以开始作为一个团队向前迈进。

8.考虑几种替代方案

正如精益软件开发告诉我们的那样，我们不应该尽早采取架构策略，而应该考虑几种替代方案，并且只要它们仍然可行，就让这些替代方案对我们“开放”。这意味着，当您在项目早期构想架构时，您应该真正设想出几种可能的架构。公平地说，这种策略并不是新的，事实上，这种策略已经在IT架构社区中推广了几十年，尽管并不总是如此。

9.记住企业约束

除最新组织外，所有组织都拥有现有的技术基础设施。更成熟的组织可能有：

• 他们正在努力实现的技术基础设施的“前景”愿景
  
• 企业级标准和指南 - 用于开发，数据，用户界面，安全性等 - 项目团队应遵循的标准和指南
  
• 用于降低总体开发和运营成本的战略性重用策略
  
• 企业架构，战略重用和/或类似的团队，负责发展和推广这些事物
  
• 运营和支持组织，有时也称为系统管理组织，负责在生产中运行组织的系统
  

关键是这些企业级考虑因素为开发团队提供了挑战和机遇。虽然每次构建一个新系统时从一个干净的架构板开始会很棒，但实际情况是在绝大多数情况下策略都是不合适的。多年来我见过几个敏捷项目团队因为他们选择重新开始，声称他们的架构随着时间的推移而出现，他们有勇气担心明天明天的问题，他们制作了潜在的可交付软件。定期，并基本上嘲弄任何其他敏捷的言论，他们认为这些言论证明了他们的愚弄。训练有素的团队构建系统，其架构出现在他们工作的组织环境中。他们谦虚地认识到他们无法做出他们想要的所有技术决策，而是受到现有基础设施和愿景的限制。此外，他们还生产可在组织生态系统中使用的可消耗解决方案。

幸运的是，企业关注的焦点也很多。通过利用现有的基础架构团队，可以更快地提供，因为他们的构建更少。通过使用现有技术，或者至少通过使用企业愿景中提到的新技术（对您的组织来说是新的），他们通过帮助最小化运营成本来降低系统的总体拥有成本（TCO）。通过遵循公司发展准则，它们有助于提高工作的一致性和质量，增加其可维护性，以便将来负责发展和维护工作。顺便说一句，软件开发上下文框架（SDCF）的企业规程扩展因子是八个中唯一的扩展因子，这使得开发团队可能更容易实现，因为这个因素远离项目级别的重点（ “容易”的情况）到企业层面的焦点（“硬”情况）。

那你怎么做的？最低限度，企业架构师，运营团队等企业集团是重要的利益相关者，应由您的产品所有者代表。对于您的企业体系结构组，其中一个或多个可能成为您的开发团队的活跃成员，具有架构所有者的角色。对于其他组，产品所有者可以根据需要和适当的即兴基础选择让他们作为域或技术专家参与您的团队。

10.轻装上阵

您的架构工作的一个目标应该是轻装上阵，尽可能灵活。当一个五页的文档可以做时，不要创建一个五十页的文档。当图表执行时，不要创建一个五页的文档。当隐喻可以做时，不要创建图表。记住“他们不会读它（TAGRI）”的原则。

不确定如何创建文档？错误的是因为你可以随时回到白板，但是你浪费了创建你不需要的工件或者为工件添加不必要的细节的时间已经一去不复返了。您的目标应该是考虑项目团队（或组织甚至行业所面临的关键问题，具体取决于您的范围），不应该创建大量的文档。最大化股东投资回报率的原则告诉您要专注于高价值的活动，例如作为一个团队解决困难问题并达成共同愿景。同样，它告诉您要避免低价值的活动，例如撰写详细的文档或开发分数漂亮的图表。这些活动往往令人感到欣慰，因为它们提供了进步的幻觉，如果你试图避免处理棘手的问题，就会为你提供一个离题的来源，但实际上很少像你想象的那样有效，因为其他人很少看到比作者。原则软件是您的主要目标意味着您应该对您的架构进行建模，直到您认为自己有可行的策略为止，此时您应该继续开始开发软件而不是文档。

您何时想撰写架构文档？在我看来，有两个例子让它变得“敏捷”。首先，当您拥有分布式开发团队并且无法找到更有效的沟通方式（例如面对面交谈）时，文档就是一种选择。其次，在项目结束时，您希望留下足够的文档，以便其他人可以在以后了解您的方法。现实情况是，对于相当复杂的系统来说，记录代码中的所有内容是非常困难的，如果不是不可能的，当然也不可取。有时，描述您的体系结构的最佳位置是简要的概述文档。本文档应侧重于解释您的架构的关键方面，可能由您的导航图捕获，它可能包括关键架构要求的摘要，以及对您所做的“可疑”方面背后的关键决策的解释。与往常一样，如果您要创建一个架构文档，那么它应该增加正值，理想情况下应该以最有效的方式执行。

很多人在发现架构没有“记录良好”时会感到担心，无论这意味着什么。我并不是很担心这个问题，但我担心的是架构是否真实，以及开发人员是否理解并接受它。如果您要优先考虑您的体系结构文档，拥有可行的体系结构，让开发人员理解该体系结构，并让所有开发人员都能使用它，那么我怀疑文档将在该列表中排在最后。想一想。

11.证明你的架构

实践证明它与代码指出模型只是一个抽象，一个看似非常好的模型在实践中可能实际上并非如此，你可以肯定知道的唯一方法是通过实现验证你的模型。这意味着你应该证明你的架构是有效的，XP称之为尖峰，RUP称为架构原型。当您的架构呼唤一些对您来说不熟悉的东西时，也许您是第一次使用两个或更多产品，您应该花时间来探索这种方法是否能够如何工作以及它是如何工作的原则快速反馈。记住要获得项目利益相关者的许可才能完成这项工作，因为这是他们花的钱。有时您会通过努力发现原始方法不起作用，我希望尽早发现，有时您会发现您的方法实际上是如何工作的（而不是您认为它的工作方式）。架构尖峰/原型的开发有助于降低项目风险，因为您可以快速发现您的方法是否可行，您还没有简单地制作象牙塔架构。

图5概述了优先需求“最佳实践”的敏捷方法。通过对交付生命周期的风险价值方法，Scrum价值驱动生命周期的扩展，您将确定解决项目主要技术风险的少数需求。例如，如果您的要求表明您的系统必须能够在10小时内每秒处理4,000个事务，那么这将是一个明确包含某些技术风险的要求。这是您希望在项目早期实现的一种要求，以确保您的体系结构真正起作用。我的一般规则是，当你进入为期6个月的项目仅18天而不是在“6个月项目”的8个月点结束时，最好发现你的架构策略需要重新考虑。这意味着，如果技术风险要求不在积压的首位，那么您需要与产品所有者密切合作，以说服他们重新确定优先级不高的要求。但是，如果您无法说服您的产品所有者这样做（我在实践中从未遇到过这个问题，但认识到可能会发生这种情况），那么您需要尊重他们的决定并接受以后证明您的架构的风险生命周期。

图5.工作积压。

12.传达您的架构

有两个主要受众，您的架构的沟通很重要：您的开发团队和项目利益相关者。为了促进您的开发团队之间的沟通，我坚信您应该遵循公开展示模型的所有架构图，因为一个严密保密的架构不是一个架构，它只是一个徒劳无益的自我锻炼。我参与了几个项目，我们成功地维护了一个专门用于架构图表的白板，让它们公开显示给项目中的每个开发人员以及偶然走过的任何其他人。我们还允许任何想要在图表中添加评论或建议的人，按照开放和诚实的沟通原则以及集体所有权的实践，因为我们希望他们对我们的工作有所反馈。我们没有什么可隐瞒和信任的，其他人愿意帮助我们（他们确实）。

在项目开始时，在整个项目中不那么频繁，您经常会发现需要使图表“看起来很漂亮”，这样您就可以将它们呈现给您的项目利益相关者。您的利益相关者希望了解什么是什么您打算采取的方法来确定您是否明智地投入资源，这意味着您需要建立模型来沟通和定位您的某些模型，以便其他人可以理解它们。这可能意味着您需要花时间来清理模型以使其可呈现以及为它们编写概述文档。为了保持尽可能灵活，有目的的模型原则告诉您，您应该确切地知道您正在为谁开发模型以及他们将使用它们，以便您可以专注于所需的最小努力。向重要的项目利益相关者进行演示，这些工作往往令开发人员烦恼和分散注意力，这对项目的成功至关重要，因为它们为您提供了获得项目支持和获取所需资源的机会。此外，您可以提升让您可以积极参与项目的利益相关者的重要性（如果您没有可用的利益相关者，则无法遵循主动利益相关方参与的做法）。

准备好在演示文稿中传达您的架构，没有理由不能保持演示文稿的敏捷性。

13.考虑未来，但不要过度建设（推迟承诺）

我怀疑关于敏捷架构建模的最具争议性的概念是你应该考虑未来的变化，但在你真正需要之前不要采取行动。换句话说，不要过度构建你的系统，但同时要聪明一点。XP社区对于过度构建软件的概念相当直率，他们相信“你无论如何都不需要它”（YAGNI）。基本思想是你无法准确预测未来[1]，因此不应该为未来的可能性而努力。相反，您今天应该专注于构建您现在需要的东西并干净地构建它，以便您的软件在需要时易于更改。明天，当您发现需要更改软件以满足新要求时，请更改它。当您过度构建软件以更加通用时，为了满足未来的潜在需求，您实际上正在做出非常严肃的权衡：

• 很难估计你正在生产的实际价值。您并不专注于满足当今的需求，导致您不会为您的用户带来直接的价值。我参与了几个项目，前几个月，在少数情况下，前几个季度，我们的工作重点是开发通用基础架构（持久性框架，消息传递框架等）。技术上有趣的东西，我们肯定有很多乐趣构建它们，但对我们的用户没有任何价值。
  
• 你在猜。你真的不知道你是否甚至需要你正在建造的任何东西 - 当一辆大众汽车足够时你可能正在建造一辆保时捷。
  
• 你增加了维护负担。您今天过度建造的任何东西都需要在项目的整个生命周期中进行测试和维护，这违反了Travel Light的原则。
  
• 目前尚不清楚它需要在多大程度上进行测试。当你过度建造某些东西时，唯一可以准确验证它的方法就是通过虚构的反馈 - 没有人要求你过度建造任何东西，所以没有人可以去验证你的工作。此外，大多数开发团队都会测试风险，但如果您猜测需求，那么您也会猜测风险级别。
  

所以你怎么能对这一切都很聪明？虽然您不希望根据未来/神话要求过度构建系统，但考虑未来并没有任何问题。这是一个两阶段战略：

• 初始建模。做一些初步的架构，设想思考问题，探索关键概念，从而让你朝着正确的方向前进。这并不意味着您需要创建大量的架构文档，尽管您可能会进行一些建模，是的，egads！，甚至可以创建足够的架构文档来满足您的需求。
  
• 推迟设计决策。精益软件开发的原则之一是推迟对您需要做出决定的最后可能时刻的承诺，从而提高您的灵活性并提高您的成功机会。
  

一个有趣的策略是变更案例建模。变更案例用于描述系统的新潜在要求或对现有要求的修改。变更案例是您未来可能需要或可能不需要支持的要求，但您今天绝对不需要支持。变更案例通常是与项目利益相关者进行头脑风暴的结果，其中诸如“业务如何变化？”等问题。“什么立法可以改变？” “你的竞争对手在做什么？”和“还有谁可能会使用该系统以及如何使用？”在技术方面，开发人员经常会提出诸如“什么技术可以改变？”等基本问题。和“我们需要与哪些系统进行交互？”这将导致识别变更案例。变更案例应该是现实的，例如“我们为银行进入保险业务”或“我们需要支持我们系统中的[INSERT FLASHY NEW TECHNOLOGY]”是合理的变更案例，但“我们的销售人员被不明飞行物绑架” “T。此外，变更案例通常描述的要求与您当前正在处理的要求相当不同，这些要求可能会导致重大的返工。通过识别变更案例，您现在可以智能地选择看起来与架构或设计决策相同的内容。当您的当前要求不足以帮助您在备选方案之间进行选择时，您应该只将相关的变更案例纳入决策过程。另一个优点是你现在可以向你的项目利益相关者解释为什么你选择一种方法而不是另一种方法，因为我想说你有一个故事要讲。但是，我不能强调改变案例不应该被用作为你的系统镀金的借口。保持敏捷，不要过度构建系统。那么当你认为你有一个你真正相信现在需要实施的变革案例时，你会怎么做？简单 - 与项目利益相关者讨论。询问他们是否立即要求变更案例，如果是，则相应地采取行动。如果这不是一个直接的要求，那么接受这个事实并继续前进。永远不要忘记项目利益相关者有责任确定需求的优先级，而不是您的需求。

未来的建模是否会受到损害？这是一个滑坡，因为我怀疑如果你建模它然后你更有可能建立它。我相信，这需要严格的纪律，不要过度建造，因为一旦你把它作为一系列气泡和线条捕获，就很容易让自己相信过度建造一次就没有坏处。已经说过，在讨论变更案例的时候绘制一些丢弃的草图并没有什么不妥，只是不要过度建模你打算保留的任何模型。

14.采用多视图方法

敏捷建模的多模型原则建议您认识到，因为现代系统很复杂，您需要考虑架构中的一系列视图。虽然它们采用不同的方法，但多视图策略是现代架构框架中的基本概念，例如Zachman框架，TOGAF，4 + 1等。这些框架中的每一个都有很好的理由来选择视图，它们在实践中似乎都运行良好，它们都可以灵活地进行处理，所以我的建议是检查您的选项并选择最能反映出来的架构框架。您组织的文化。我的目标不是提出另一个架构框架，而是让您了解它们及其基本概念。图6概述了软件/系统架构师需要关注的视图和关注点（通常称为服务质量要求）。

图6.架构视图和关注点。

视图/视点被捕获为图表和文本描述（例如用例，技术规范或散文）的组合。潜在的问题，可能是您自己的观点，您的架构应该解决的观点包括：

• 用法/业务流程
  
• 用户界面
  
• 系统界面
  
• 网络
  
• 部署
  
• 硬件
  
• 数据存储
  
• 数据传输
  
• 活动
  
• 代码/组件分发
  
• 功能/逻辑/服务
  

借用面向方面编程（AOP）的语言，您的架构也可能需要考虑“横切关注点”。这些问题/观点也应该通过您的架构视图来解决，在某些情况下可能是您自己的特定视图。这些担忧包括：

• 分层/分区
  
• 重用
  
• 质量和验证
  
• 准确性和及时性
  
• 可靠性，可用性，可维护性和性能
  
• 环境（绿色计算问题）
  
• 定制点
  
• 可消耗性（包括（de）安装的简易性，支持级别，可用性，......）
  
• 并发
  
• 安全
  
• 国际化
  
• 条例
  
• 维护，操作和支持问题
  

这意味着，任何担任架构师角色的人都需要拥有广泛的技能才能发挥作用，他们需要摆脱过度专业化的传统哲学，更多地是一个普遍化的专家。最低限度的是，他们应该从简单的数据架构师，安全架构师或网络架构师转变为架构师。仅仅是一名架构师也可能过于专业化，但这取决于具体情况。真正的专业人士力求拥有广泛的技能以及一个或多个专业。

15.这是如何工作的？

我所描述的架构方法与许多组织目前正在做的事情明显不同。表1比较并对比了许多组织中常见的架构实践与敏捷对应的架构实践。显然，这有很大的不同。敏捷方法之所以有效，是因为它专注于团队合作的人员。敏捷建模认识到人们是错误的，他们不太可能从一开始就获得正确的架构，因此需要有机会根据实施工作的反馈行事。当敏捷架构师是开发团队的高效成员，并且当开发团队参与开始的架构工作时，他们不需要全面的文档，导航图就足够了（授予，当这不是案件文件，希望最小，可能是必需的）。不需要架构评论，因为架构是通过架构原型设计/峰值的具体反馈来证明的，因为人们可以看到架构发展，因为您的模型公开展示供所有人查看。敏捷架构师有勇气专注于解决当今的问题并相信他们明天可以解决明天的问题（Beck，2000），以及认识到他们无法准确预测未来并因此选择不过度构建他们的架构的谦虚。

表1.比较常见和敏捷架构实践。

架构师们很受尊重，经常被放在基座上，甚至更糟的是，被放在基座上

16.解决敏捷和架构周围的神话

我想通过解决一些与世界各地的组织合作时仍然遇到的常见神话来结束这篇文章。

• 敏捷者不做架构。我的希望是，这篇文章将把这个神话牢牢地放在一边。
  
• 您需要进行详细的前期架构建模。您应该进行一些前期架构建模，以确定您的一般技术策略，识别您可能遇到的潜在技术挑战，并帮助您在团队中围绕技术方向达成共识。关键是你不需要很多细节来实现这些目标。采用“大型模型预测（BMUF）”方法是一种选择，这种方法在理论上听起来很棒，特别是如果你是一名专业建模师，但在实践中通常被证明是一个相当差的人。BMUF战略导致糟糕的决策和解决方案不太可能满足利益相关者的实际需求，降低您支持不断变化的需求的能力，并导致士气低落。
  
• 架构师负责架构。虽然许多组织选择支持主要负责架构活动的专业架构师，但事实证明这在实践中是一个相当糟糕的选择，因为开发人员可能会将架构师视为“象牙塔”并且经常会选择忽略它们。正如您在本文中看到的那样，有效的架构策略本质上是协作的，而不是独裁的。