语言 Chinese, Simplified

SEO Title

Architecture Envisioning: An Agile Core Practice

一种常见的敏捷实践是在生命周期的早期执行一些高级架构建模。这有助于在团队内部和关键利益相关者之间形成关于您的技术战略的共同点。此时的目标是确定架构策略，而不是编写大量文档。您将在开发周期后期通过JIT模型存储会话和TDD处理设计细节。本文讨论了几个关键问题：

什么时候应该进行初步的敏捷架构建模？
为什么要进行一些初始敏捷架构建模？
你最初应该建模什么？
你应该使用什么建模工具？
你真的需要做多少建模？
为什么你需要做的初始架构建模比你想象的要少？
人们真的这样做吗？
分开的想法

1.您应该何时进行初始敏捷架构建模？

敏捷模型驱动开发（AMDD），参见图1，明确包括敏捷项目的迭代0期间的初始架构建模工作（某些进程可能称之为预热，启动或启动阶段）。初始体系结构建模对于将敏捷软件开发技术扩展到大型，复杂或全球分布式开发（GDD）工作尤为重要。

图1. AMDD生命周期：项目视点。

2.为什么要进行一些初步的敏捷架构建模？

有些人会告诉你，根本不需要进行任何初始架构建模。但是，我的经验是，以敏捷方式进行一些初始架构建模可以带来以下好处：

提高生产力。您可以考虑项目所面临的一些关键技术问题，并可能避免失去无用的技术路径。
降低技术风险。您的团队可以获得具有指导性愿景的优势，而不必过度构建您的系统 - 仅仅因为您已经建模它并不意味着您必须构建它。
缩短开发时间。最初的敏捷架构建模使您能够为项目提供更好的成本和时间估算，这是管理层需要的两条信息。
改善沟通。拥有高级架构模型可以帮助您沟通您认为自己将要构建的内容以及您认为构建它的方式，这是管理层所需的两个更重要的信息。
扩展敏捷软件开发。您的初始架构模型将成为任何“大规模敏捷”工作中的关键工作产品，因为它提供了子团队在整个项目中定义和指导其工作所需的技术指导。
改善团队组织。围绕建筑或业务线组织有效的团队，而不是围绕工作职能。当您扩展到更大的和/或分布式团队时，子团队应该分别负责一个或多个子系统 - 您不希望围绕工作职能组织您的子团队（例如，架构团队，开发团队），测试团队，......）因为这需要您增加文档和官僚机构的开销，从而增加风险，成本和价值实现时间。

3.企业架构实用指南

你最初应该建模什么？
在项目早期，您至少需要了解如何构建系统。它是大型机COBOL应用程序吗？一个.Net应用程序？ J2EE？别的什么？为此，项目的开发人员将聚集在一个房间，通常围绕白板，讨论，然后勾画出系统的潜在架构。此建模工作基于您的初始高级需求建模工作，并与之并行执行。您的架构将随着时间的推移而发展，因此它不需要非常详细（它现在只需要足够好），并且需要编写很少的文档（如果有的话）。

当我进行初始架构建模时，我通常会关注高级自由格式图表，这些图表概述了我们如何构建系统。我通常会关注：

技术图
用户界面（UI）流程
领域模型
改变案例

3.1技术图

通常某种形式的技术堆栈图（图2）或部署图都可以（图3）。这些图非常有用，因为它们描述了主要的软件和硬件组件以及它们如何在高级别上进行交互。这包括遗留资产，包括遗留数据库和遗留系统，可能需要在项目后期更详细地进行分析。现在，您的目标应该是识别这些资产，并讨论它们作为系统功能和/或数据来源的可行性。

图2.技术堆栈图

图3. UML部署图。

您还将在此时确定技术限制。例如，尽管您希望使用最新版本的DB2，但遗憾的是您的企业数据库标准是Oracle（如图2所示），因此您在该架构选择中受到限制。

3.2用户界面流模型

要创建的另一个常见图表是用户界面（UI）导航或UI流程图，请参见图4，以探索如何通过探索主要UI元素（包括屏幕/页面和报告）之间的流程来构建系统的UI。这对您的系统的成功至关重要，因为用户界面是您的利益相关者的系统。不是技术。不是数据。你正在使用的框架并不是很酷。如果您没有有效地构建用户界面，那么您将面临构建利益相关者不感兴趣的系统的风险。

图4. UI流程图。

3.3域模型

初始架构建模工作的一部分，特别是业务应用程序，可能包括高级域模型的开发，如图5所示。此模型应该非常小，捕获主要业务实体及其之间的关系。有些人认为这种类型的模型是初始需求模型而不是初始架构模型 - 它并不重要，因为正如您在图1中看到的那样，这两个初始建模工作无论如何都是并行执行的。图5描绘了使用UML数据建模符号的示例（您可以使用您在敏捷数据建模时喜欢的任何符号，我更喜欢UML）。初始域模型将用于帮助指导物理数据模型以及类设计，可能通过UML类图捕获。我最初会使用白板创建这种类型的图表，然后如果这样做的努力提供了足够的价值，我可能会将其转移到绘图工具中。

图5.初始域模型。

3.4变更案例

最后，我有时会考虑捕获的另一种常见架构模型是更改案例，这些更改案例是系统可能需要支持的潜在架构级别要求。图6提供了两个变更案例的示例，描述了潜在的技术变化，第二个变更了潜在的业务变化。更改案例允许您测试架构的长期可行性，而无需过度构建系统，因为您可以考虑可能的更改的影响，以确保您的系统仍然可以工作。

图6.两个更改案例。

变更案例：注册将完全通过互联网进行。
可能性：中等可能性在两到三年内，很可能在十年内。
影响：未知。虽然注册将于9月开始在线提供，但我们目前预计今年将通过互联网进行不到四分之一的注册。在高峰使用期间，响应时间将是一个问题，这是在每个学期开课前两周，以及课程的第一周。

-------------------------------------------------- -------------------------------------------------- --------

改变案例：大学将开设一个新校区。
可能性：确定。据宣布，新校区将在两年内开放。
影响：大。学生可以在任一校区的课程中注册。一些教师将在两个校区任教。一些部门，如计算机科学和哲学，计划将他们的整个课程搬到新校区。大多数学生只想在两个校区之一安排课程的可能性很大，所以我们需要让这个很容易支持。

4.您应该使用哪些建模工具？

敏捷建模者将使用最简单的工具来完成工作。正如您在图2和图4中所看到的，我发现白板图通常足以满足初始架构模型的需要。您的目标是在生命周期的这一点思考关键技术问题，而不是创建漂亮的图表。使用更复杂的绘图工具没有任何问题，如图3和图5所示，只需确保您投入的投资是值得的。这一切都取决于你工作的情况。此外，纸质工具也很常见。例如，我很想在索引卡上捕获图6的更改案例，并且只在适当时使用更复杂的工具捕获它们。

5.你应该做多少初步的建筑模型？

让我们考虑一下项目团队可能会遇到的几种常见情况，然后再考虑在这种情况下多少架构建模。这些情况是：

您的团队正在使用之前已经使用过的已知技术。这是你可以找到的最简单的情况，最多我怀疑你需要创建一个单一的白板草图，以确保每个人都在努力达到同样的愿景，坦率地说，你可能甚至不需要这样。例如，如果这是您的团队使用Websphere和DB2构建的第十个基于Web的应用程序，那么您真正需要做多少架构建模？
您对这些技术几乎没有经验。传统主义者经常告诉你，为了降低你应该详细模拟一切的风险，但是如果你退后一步思考它，这实际上会增加你的风险。当你不知道自己在做什么时，做很多详细的建模真的有意义吗？不，所有可能实现的是你浪费了大量时间，写了很多文档，开发人员可能会忽略这些文档，因为他们很快就会知道你不知道你在说什么，它给你错误的信心，你知道你在做什么，这可能会给管理层一种错误的信心，即团队有一个坚实的架构计划。你真正想做的是做一些建模，以帮助你识别你不知道的东西，如果可能的话，你想邀请那些有你缺席经验的团队成员。然后，您需要通过建筑原型设计/尖峰技术获得实际技术本身的实践经验，然后基于该经验发展您的建筑模型，以便它们反映实际工作的内容。换句话说，让您的架构在整个项目中出现。
在中间的某个地方。这是您通常会发现自己的地方：也许您有一些但不是所有技术的经验，或许您的团队对这些技术有经验，但根本没有将它们全部一起使用。在诸如此类的中间情况下，最初（甚至几天）进行更多建模是有意义的，以便识别潜在风险和可能的减轻风险的策略。在这种情况下，建模是有意义的，因为它使您能够在团队中定义共享的技术愿景，并可能通过重大问题进行思考。换句话说，一些初始架构建模将为您的团队提供价值。

图7描绘了建模的价值，表明模型在它们几乎不够好时达到它们的最大值点，并且对于初始架构设想，这通常是在几天或一周左右之后。很多人最初对这种说法感到震惊，但是当你回想起你曾经参与过的所有项目时，如果你被允许的话，有多少项目，你可以在一周之内建立一个非常好的初始架构策略把几个聪明的人放在一个有很多白板的房间里？我现在已经问了几千人的这个问题，只被告知了一些不真实的项目。很多人认为他们有例子没有成功，但他们的问题几乎总是围绕着无法让那些知道自己在做什么的人或者让人们聚集在一起的后勤问题。需要超过一周的人员处于团队分布的情况下，因此他们需要投入更多时间来识别子系统/组件及其接口，以便他们可以围绕实施这些子系统或子组件来组织子团队（a实践称为API First或Conway's Law）。或者他们正在研究生命关键系统（或者在几个军事项目中的死亡关键系统），或者处于需要对软件或硬件进行大量投资的情况下。

图7.建模的价值。

6.为什么你需要做比传统主义者更少的初始建模？

传统建模者假设需要在项目开始时详细建模问题和解决方案域。我将此称为“大型建模前端（BMUF）”，其中包含“前期大需求（BRUF）”，您可以在生命周期的早期创建详细的需求规范，并在此处“大型设计预先（BDUF）”在生命周期的早期创建详细的需求规范。当你是一名建模专家时，这些做法是有意义的，而且确实有足够的传统建模者似乎总是有理由说明BMUF为什么是理想的。表1总结了在项目早期进行详细架构模型的常见论据，并论证了为什么它们是错误的。

表1.建筑BMUF的论点和反驳论据。

争论	相反的观点
我们可以预先考虑技术细节	对于非常简单的系统可能也是如此，但对于即使是中等复杂的系统，由于每种技术的各种细微差别，组件的使用模式不断变化以及技术本身的变化，我们也无法通过细节进行思考。看起来您的建筑模型中的所有内容都可以正常工作，但在您使用代码证明它之前，然后根据您所学到的内容采取行动，您将永远无法确定。最好的架构随着时间的推移而发展，它们不是预先定义的。
我们需要确定最佳技术战略	是的，您需要确定一个好的策略，但这并不意味着您需要编写大量详细的文档。使用BDUF方法时，如果您对问题域的了解最少，则会要求您做出严肃的技术决策，从而增加选择错误路径的可能性。精益/敏捷方法建议您在最后可能的时刻做出这些决定，而不是在开始时。
我们需要首先建立技术基础	您需要一个技术愿景来努力实现团队成员之间的良好沟通/协作。详细的架构/设计会激励您过度构建系统 - 它在设计中，因此无论利益相关者是否真的需要，您都可以更好地构建它。有多少次你看到项目团队在项目的前六个月花费了大量的框架来构建支持所有未来需求的框架，却发现根本不需要很多框架？除非你完全正确地完成设计，这在实践中很难做到，否则你最终的建设将远远超出你的需求。
我们需要为编码器指定设计	编码员真的很聪明。他们可能需要一些指导和领导，但他们很可能不需要详细说明该做什么。事实上，当您向编码员提供详细的架构时，您会将项目置于风险之中。一些程序员可能会选择不遵循设计，因为他们相信他们知道的更好（也许他们知道）。更糟糕的是，您所做的建模和文档越多，由于您在工作中所做的投资，您将承诺采用文档化方法的可能性就越大。即使已知设计存在问题，也会发生这种情况，因为一旦您开始沿着特定路径重新设计方法，通常会花费太多精力。
架构软件就像构建桥梁一样	桥梁类比通常是这样的：“构建桥梁是一件非常复杂的事情，就像构建软件一样。桥梁构建者预先创建复杂的蓝图然后为这些计划工作，因此我们也应该做同样的事情。” 如果某人没有建立桥梁和构建软件的直接经验，那么我们不应该质疑他们的假设吗？我认识一些物理建筑师，他们的工作方式比你想象的更具创造性和进化性。为了看到一位世界级的建筑师在行动，我强烈建议观看纪录片“Frank Gehry的草图”。我可以非常安全地说Gehry是一个敏捷的建模者，而不是传统的建模师。所以，也许桥梁类比确实存在，但不是传统主义者的想法。
应根据需求详细定义体系结构	当您在家中装修房间时，您是否曾尝试完全指定您的设计？无论你付出多少努力，你总会发现沙发处于错误的角度，墙壁艺术不适用于地毯，等等。你总是需要调整你的设计，有时甚至做出重大改变。如果你不能做一些简单的事情，比如预先指定一个房间的装饰，那么你认为你可以为一个更复杂的数量级的系统做同样的事情吗？人们不知道他们想要什么;他们至多可以理解他们的目标/意图。人们非常善于说出他们不喜欢的东西，并提供可能改进的建议。这意味着需要采用渐进的方法来定期获得反馈，而不是基于文档的连续方法。当然，这假设您实际上想要建立一个反映其利益相关者需求的系统。底线是需求在整个项目中发生变化，您需要接受并相应地采取行动。
详细的文档和模型增加了价值	这个论点可能部分正确，尽管在生命周期的早期编写全面的文档是错误的时间。敏捷建模建议您仅在捕获的信息已稳定且有人理解并愿意承担该文档的总体拥有成本（TCO）时才编写文档。您不希望记录投机性事物，并且在生命周期的早期记录需求和建议的设计显然是推测性的，因为投机性事物倾向于改变，从而提高该文档的TCO。
没有证据表明进化技术是有效的	实际上，是的。当人们要求“无可辩驳的证据”时，他们经常说的是他们不想偏离他们偏好的工作方式。采用传统方法的证据远远少于我们今天支持进化方法的证据，而且我认为传统的记录不言自明 - 如果你愿意接受它，证据就明确指出了BMUF。

Think big but act small.

7.人们实际上是这样做的吗？

是!以下是我多年来所做的几项调查的一些证据：

初始架构建模有效。在2007年3月的DDJ Agile Adoption Rate调查中，我问的一个问题是敏捷团队的初始敏捷架构建模有多么有效。结果总结在图8的直方图中。正如您所看到的，敏捷实际上确实在实践中进行了模型化。 77％的受访者表示他们的组织正在使用敏捷，这表明这些团队也在进行初步的高级敏捷架构建模，并且88％的团队认为这些努力是值得的（他们给出的评级为3或更高） 5）。
大多数敏捷团队正在进行初始架构建模。图8显示77％的敏捷团队正在执行初始架构建模。表2总结了2009年敏捷项目启动调查的结果，显示83％的受访者表示他们在最近的敏捷项目中进行了某种形式的架构建模。它还表明，一些团队正在利用企业模型，希望他们能够与敏捷的企业架构团队进行交互，有时甚至是行业模型。
正在应用各种策略。 DDJ 2008建模和文档调查发现，草图绘制是最常见的主要建模方法（参见图9）。它还发现，敏捷主义者比传统主义者更有可能在软件开发项目上进行建模。最后，它发现一些敏捷团队正在使用基于软件的建模工具（SBMT），也称为计算机辅助软件工程（CASE）工具。
基于Internet的开发很常见。许多开源系统和其他共享源环境采用一种方法，在他们开始工作时，就如何构建某些内容以及一些工作代码达成一致意见。
图8.敏捷团队建模的采用率。

表2.敏捷项目团队初始架构策略的采用率（2009年敏捷项目启动调查）。

Rate	Strategy	Discussion
70%	高级初始架构建模	我很惊讶这个数字并不高，尽管暗示正在进行详细的初始架构建模的团队很可能也在进行高级初始架构建模是合理的。如下所示，76％的团队进行某种初始架构建模。
25%	详细的初始架构建模	我很惊讶这个数字很高，也许这表明组织尚未完全从传统战略过渡到敏捷战略。
12%	最初的架构模型提供给团队	不幸的是，我没有问为什么会发生这种情况。可能的原因是这是由于瀑布驱动的合同，例如在外包情况下，客户为系统开发IT架构并将其提供给服务提供商，或者组织仍然具有瀑布驱动的治理策略，其中架构工作由不同于开发系统的团队执行。
14%	使用企业模型作为参考	显然，一些敏捷团队实际上采用了严谨的开发方法，他们利用企业模型，更好地与敏捷的企业架构师密切合作。
12%	使用行业模型作为参考	在某些行业，例如保险业或电信行业，有行业联盟或大型供应商（例如IBM），它们产生“行业标准”架构模型。这些模型的目标是它们应该有助于推动开发项目的一些业务架构。行业联盟模型的一个例子是ACORD保险数据标准，供应商提供的模型的一个例子是IBM保险应用程序架构。
76%	做某种形式的初始架构建模（高级或详细）	超过四分之三的敏捷团队进行某种初始架构建模。这个速率非常接近DDJ Agile Adoption Rate调查发现的初始敏捷架构建模的77％。
83%	进行某种形式的初始架构建模（高级或详细）或提供初始架构模型	8个敏捷团队中有近7个基于某种初始架构模型开展工作。
86%	进行某种形式的初始架构建模，或提供初始模型，或利用可用模型（企业或行业）	绝大多数团队采用模型驱动的架构方法。然而，这并不意味着他们创建了巨大的建筑大纲（正如您所看到的，只有少数敏捷团队似乎这样做，而大多数人采取轻量级，高级别的方法）。

Figure 9. Primary approaches to modeling.

8.分手思考

您应该努力为手头的情况做足够的建模，而不是更多。这意味着每个项目团队将做多少建模没有一个正确的答案，相反，它会因团队而异。我的理念是，可重复的结果，在这种情况下，在团队中具有共享的架构愿景，远比遵循可重复的流程更重要，该流程确保每个团队每次都进行相同数量的建模。

在以后的迭代中，您的初始需求和初始架构师模型都需要随着您了解更多而发展，但目前的目标是获得一些不够好的东西，以便您的团队可以开始工作。在后续版本中，您可以决定将迭代0缩短到几天，几个小时，甚至可以根据您的情况完全删除它。秘诀是保持简单。您不需要为很多细节建模，只需要足够的模型。如果您正在编写用例，这可能意味着点状注释足够好。如果您正在建模白板草图或CRC卡集合可能已经足够好了。对于您的体系结构，白板草图概述了系统如何端到端构建，这已经足够了。我不能这么说：你的目标是建立一个共同的理解，它不是写详细的文档。一个关键的成功因素是使用包容性建模技术，使利益相关者积极参与。

许多传统开发人员都会采用灵活的初始建模方法，因为多年来他们被告知需要在项目早期定义综合模型。敏捷软件开发不是连续的，它是迭代的和渐进的（进化的）。通过演化方法，在模型存储会话的开发迭代期间，及时（JIT）完成详细建模。

原文：http://agilemodeling.com/essays/initialArchitectureModeling.htm

本文：https://pub.intelligentx.net/architecture-envisioning-agile-core-practice

讨论：加入知识星球或者小红圈【首席架构师圈】