最有效的架构建模策略就是刚刚好


敏捷架构思维的一个重要方面：刚刚好（JBGE： just barely good enough），它用来创建足以满足您的情况上下文的工件即可。

出于某种原因，人们认为 JBGE 意味着人工智能不是很好，而事实上，这与事实大相径庭。静下心来想一想，如果架构模型是 JBGE，那么顾名思义，它就处于可能达到的最有效点。

如果您正在研究一个架构模型，而它还不够完善，那么您仍然可以在其中投入更多精力，并从中获益（当然，前提是您所做的工作能使模型更接近其预期目的）。

但是，如果你的架构模型已经是 JBGE（或更好），那么在它上面做更多的工作显然是一种浪费：一旦你的模型达到了预期目的，那么在它上面的任何更多投资都只是忙碌的工作。

您仍有可能过度设计架构模型
理想情况下，您的架构模型应该是 JBGE。不幸的是，这并不是一个理想的世界。有三个常见原因可能会导致您的架构模型超出理想状态：

  • 意外。你会在模型上投入太多精力，在工作过程中无意间偏离了目标。例如，我真的需要图 1 中数值曲线最右端的箭头吗？如果不需要，那么图表就不仅仅是勉强够用了。
  • 有目的性。当你刚刚接触 JBGE 概念时，一开始会有点害怕。为了以防万一，故意做得过多，做得比要求的更多，这可能会让人感到欣慰。然而，现实情况是，如果日后你确实意识到你需要更多的东西或其他东西，你很可能会在那个时候模拟它。
  • 改变。有时，您创建了一个 JBGE 架构模型，但后来情况发生了变化，您发现模型中包含了额外的材料、过时的材料或根本就缺少材料。


架构师也是人，他们不可能总是做得尽善尽美。秘诀就在于学会如何发现自己的工作已经到了勉强够用的地步，然后停止工作。说起来容易，做起来难。

JBGE 是因地制宜的
JBGE 的根本挑战在于它的情境性(上下文)。

例如，我经常在白板上画一张图来探索复杂的逻辑，画完后就把它丢掉。在这种情况下，白板上的图表并没有问题，因为它能帮助我解决我正在思考的问题。

但是，如果我们以后需要更新这个逻辑，并且希望通过图表而不是源代码来更新，那该怎么办呢？

在这种情况下，手绘草图显然不够好，我们需要使用复杂的软件工具（即使只是 PowerPoint）来创建详细的图表。

尽管敏捷模型比草图复杂得多，但我们仍然要创建一个敏捷模型，因为 JBGE 反映了实际情况的需要。

要确定一个架构模型是否符合 JBGE，您必须积极与该人工制品的直接受众合作。

  • 就业务架构模型而言，这既包括业务利益相关者，也包括将使用该模型的实施团队。
  • 如果不知道受众想要什么，就不可能切实地创建出符合 JBGE 要求的产品，这就会促使你为产品付出比实际需要多得多的努力。
  • 事实证明，这往往是白费力气，因为模型很有可能会落入敏捷建模的 "他们不会读它"（TAGRI）原则的陷阱。
  • 为了确保您知道架构模型的受众想要什么，您需要确保与他们进行良好的沟通，最好是争取利益相关者的积极参与。

JBGE ​​​​​​​并不意味着质量低劣
有些人似乎认为，JBGE 的机型质量一定很差。实际上，这些模型的质量足以胜任手头的工作。JBGE 并不是做低质量工作的借口，相反，它促使你了解工作的背景。这可能具有挑战性，因为质量是看人下菜碟：决定架构模型是否足够的是架构模型的受众，而不是架构模型的创建者。如果你的利益相关者需要一个优秀、详细的模型，那么当它达到优秀和详细的程度时，它就是一个 JBGE。

这里有一个让传统主义者不舒服的观点：当一个工件超过 JBGE 时，模型中的额外信息就会成为技术债务。  换句话说，它会降低而不是提高你的工作质量。

JBGE​​​​​​​随着时间的推移而变化
架构模型在其生命周期内可以沿着这条价值曲线双向移动。您的需求可能会发生变化，要么变得更加复杂，要么变得不那么复杂，因此您可能会选择相应地更新您的模型。如果一个模型变得不够好，那么你就需要考虑更新它。

如果一个架构模型已经足够好，那么只有当它对你其他方面的工作造成损害时，你才应该重新修改它

再举一个例子，假设我不喜欢当前的 X 轴标题，认为 "支出"（Expenditure）更好。启动 Visio、读取文件、更新文件、生成 JPG、编辑这篇文章以重新修改文本使其与图表匹配、审阅文章以确保我做对了，做任何必要的修正，然后将更改提交到版本控制，这样做值得吗？听起来至少要花费五到十分钟的时间，却几乎没有任何价值。目前的 X 轴标题还没有 "错到 "需要这样的投入（实际上，我认为目前的标题是合理的）。事实上，这种更新实际上会降低图表的价值，因为成本大于收益。

JBGE​​​​​​​比想象中来得快
传统主义者似乎认为，对建模和相应规范的大量投资会随着时间的推移不断增值。但实践表明，建模的价值来自于沟通的改善和思考问题的能力，而且这种价值很快就会达到顶峰。例如:

  • 对于最初的前期建模，通常会在几天或几周后达到顶峰（当然，对于高风险的项目，你可能希望在最初的建模上投入更多的时间）。即使是企业架构，你也只想在初始建模上投入几周时间。
  • 对于冲刺/迭代建模来说，时间更短，通常只需几个小时，
  • 而对于即兴模型风暴来说，则只需几分钟。