与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统的工作一样，并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是，敏捷专家的架构方式与传统主义者的方式略有不同。本文讨论以下问题：
- 迈向敏捷架构
- 整个生命周期中的架构
- 谁负责架构？
- 拥有“架构所有者”的角色
- 大规模的敏捷架构
- 根据需求建立您的架构
- 为您的架构建模
- 考虑几种选择
- 记住企业约束
- 旅行灯
- 用工作代码证明你的架构
- 沟通您的架构
- 想想未来，等待行动（推迟承诺）
- 采取多视图方法
- 这是如何运作的？
- 解决敏捷和架构周围的神话
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数据结构之类的新功能将需要足够的定义。有时，如果没有准确的文档，您需要对旧系统的现有接口进行分析，有时需要设计新的接口。在这两种情况下，都需要由您的团队，其他团队或合适的联合开发相应的合同模型。
您应该如何组织架构建模工作？在项目开始时，我将典型地将架构团队聚集在一个单独的房间中进行初步构想。理想情况下，这个会议将持续不超过几个小时，但在一些较大的项目上，它可能持续几天甚至几周（我会认真地质疑任何超过两周的努力）。与往常一样，建模会话越长，由于缺乏反馈而偏离航线的可能性就越大。这个建模会议的目标是就我们正在建立的系统的格局达成初步协议，或许不是达成共识，而是足够的协议，因此我们可以开始作为一个团队向前迈进。
