作为技术架构师，我们常常需要做出架构决策。这些决策通常规模宏大，重要且复杂，影响深远并跨越组织界限。
然而，每次做决定之后，我们经常会质疑自己的选择以及他人的选择。总觉得哪里不对劲。总觉得有点不对劲。总有一种不安，好像漏掉了什么。好像没考虑到某个因素。
我们为什么选择使用事件流技术来处理那个客户订单系统？这真的有意义吗？我们为什么选择特定的商用现货软件（COTS）？这个供应商真的达到我们的期望了吗？
没有人能确切地说清楚。没有任何审计记录。没有记录显示是如何做出这个决定的。没有人能回忆起当时讨论这个决策的过程。
记得有一个项目，我以架构师的身份加入了。这是一个非常大的机构，有几百名各种架构师——解决方案架构、软件架构和企业架构等等。
我本打算接手一个刚开始的应用程序，该程序的架构基础是由另一位离职的架构师搭建的。
留下了一些基本的文档，但细节不多。然而，已经有了一些重要的决定提前做好了。其中涉及一款SaaS产品，这款产品的年费高达数百万美元。虽然使用了云环境，但用途各异。还有一些数据库、数据湖以及与其他系统集成的点，这些集成点看起来有些突兀。
这是我用来完善产品其余部分并最终确定其架构和设计的基础。
基于已经为我定下的决定，我有很多这些需要自己做出的选择。但是，没有明确的框架或指导来帮我，告诉我该怎么去做。
不仅如此，我还得为自己和前任所做的决定进行辩护和解释。这一切都需要在我面前，向架构评审小组进行展示和辩护。
这个决策过程简直让人精疲力尽至极。和其他建筑师交流后，我意识到我也不是唯一一个有这种感觉的人。
我想知道这是为什么。
为什么在一个看似拥有如此巨大建筑和技术影响力的组织里，建筑设计决策的过程竟然如此耗费心力，让人感到疲惫不堪？
我意识到这是因为根本没有建筑设计决策的过程。
尽管有建筑评审委员会、企业架构的参与以及充裕的预算，IT架构师在做出架构决策时并没有一个可以遵循的流程。
我的第二个想法是，虽然我无法独自为整个公司建立那样的流程，但我至少可以为我的项目和直接团队做些事情。这可能不会十全十美，但仍然可能很有价值。
然后我开始想。到底少了什么？换句话说，正确的建筑设计决策过程应该是怎样的流程？
文档说明首先，完全没有相关文档。技术决策及其背后的理由都没有被记录。更不用说那些每年花费公司数百万美元的重大决策了。
所以我决定从这里作为起点。我开始记录实际的决策制定过程。最初的时候，我只是简单地将相关信息以自由格式文本记录在我们的Confluence上。
然后，它变得更加结构化了。最后，我开始使用一种简单却有效的格式来记录这种技术决策的流程。
我将这种结构称为技术/架构决策矩阵。它的目标是强调每个技术选项的不同方面。它不需要传达调查每个选项时的所有细节，这些细节可以留给其他类型的文档。它所做的是集中汇总每个选项最重要的方面，从而使每个选项的决策过程透明化并显而易见。
这是矩阵的结构。对于每个选项，你都需要列出以下信息：
- 选项名：一个简单的选项标识符。
- 简短描述：对该选项内容的清晰简短描述。
- 好处：该选项的好处。
- 不足：该选项的不足。
- 可能的风险：实施该选项的风险。
- 总体影响：实施该选项的总体影响（积极或消极影响）。
你也可以添加类似“费用”或“不实施的风险”这样的内容。
这样记录技术决策首先做的是帮助你整理和定义所有相关的资讯。这反过来又可以帮助你做出更加明智且因此正确的决定。
没有这些文档，决策过程就会变得杂乱无章且缺乏透明度。很难追踪和理解为何做出某些决策及其原因。很容易遗忘和忽略关键信息。
有些人可能会说，这样做只会帮助其他人更好地理解决策过程，但并不会特别帮助正在进行决策的人。但这并不正确。实际上，这对决策者也同样有帮助，可以帮助你在头脑中更好地整理思路，并以更加客观、清晰和有信息量的方式考虑每个选项。它也有助于决策者向他人传达这些选项，并从他们那里获得有用的反馈。
这对我在这个角色中帮助很大——一旦我开始记录这些技术选项，它不仅帮助了我架构方面的思考，也促进了与不同利益相关者关于各种选项的沟通和协商。
但是，仅仅单独记录各种选项是不够的。但这只是一个美妙而重要的开端。不过，事情没那么简单。
建筑决策记录上述矩阵中的选项记录有助于您以清晰透明的方式缩小范围并更清楚地选择哪个选项。但在决策之前，这会发生。简单来说，这就是你要做出特定决策的过程。
一旦做出决定，结果也需要相应记录。
这就是A DR记录或ADR发挥作用的地方。这里，我在另一篇文章中讨论过ADR及其重要性——技术决策迷失方向？使用架构决策记录这篇文章。
简单来说，这些架构决策记录对于追踪你的决策，并创建贯穿时间的决策审核记录非常重要。
回到我在这篇文章开头提到的个人例子——你有多少次看到别人做的决定却完全不明白他们为什么这么做？这其实很常见。这是因为一旦做出了技术或架构上的决定，几乎没有人会记录下来。
使用我在上面提到的ADR文章中描述的简单格式，可以大大提高了这些技术决策的可见性和透明度。无论是在Confluence、Notion还是代码仓库中的Markdown里记录这些决定，都消除了我们为何选择这条路而非那条路的猜测，从而减少了不必要的猜测。
这也减少了因为最初的理由被遗忘，导致重要决定被后来的人无意中修改的可能性。
所以，ADR（架构决策记录）是另一个简单而强大的工具，可以帮助我们更高效地制定架构决策。
现在你可能会说，这都没问题吧。但是，你又该怎么把这些真正融入到你的团队或组织中呢？对于一家大公司来说，这又是另一回事了。
你如何把这些改进落到实处，让它们融入你的组织决策流程中？对于那些没有足够权限大规模改革组织流程的人来说，你又是怎么做的呢？
这是我作为软件开发人员、技术领头人和架构师期间多次使用的一种方法——在我进入可以直接决定和影响这些事情的角色之前。
关键是建立一个清晰、透明、简洁且强大的架构和技术决策流程，并逐渐说服利益相关者其价值。说起来容易，做起来难，当然。但是，如果我们发挥创造力、持之以恒并跳出思维定式，这实际上是可行的。
每当我们想到建筑选项时，我们会进行一次评估。问题是，在很多组织里，这种评估是潜意识的。没有以清醒和有意识的方式进行，也没有被记录下来，因此无法重复进行。而且，过程也不透明。
在大型组织中实现更好的决策过程的一个方法是从小步骤开始，逐步赢得相关方和/或团队成员的支持。
第一步：做个好榜样软件架构师常常认为，他们无法改变超出自己职责和权限的事情。当然，这种情况也确实存在，但其实我们比自己想象的更有影响力和权力。
关键是，你不能仅仅命令组织去实施你提出的改变。你需要说服他们接受这些改变。
你可以从做个具体的例子开始，以后可以用它来展示你所做的事的价值。
首先，找出一个你或他人在过去或现在需要在几个选项之间做出决定的建筑相关的问题。
用上述技术决策矩阵记录正在考虑的选项，不需要太复杂，只需记录决策过程中的主要内容就行。
那么，如果过去已经基于这些选项做出了决定，记录一个简单的ADR情况。
第二步：争取一点支持一旦你记录了一些选项，并且手头有了些具体内容，就可以着手让其他人注意到这些了。
找几个像你一样受影响的团队成员或利益相关者，这些人可能包括其他架构师、开发人员、经理、产品负责人等。他们受到缺乏具体的架构决策过程的影响。
把你的记录给他们看看。解释这些文档如何有助于简化流程，同时缓解当前的一些问题。
创建一个这样的演示文稿会很有帮助，在其中列出这种流程的好处以及不实施的风险。
后一部分更重要的是，它表明了不采纳你的建议会遇到的问题。
一旦你从几个关键利益相关者那里得到了认同，并获得了实质性的支持，你就可以进入下一步了。购得支持后。
第三步：扩大更广泛的社交圈并获得认同和支持在这里，你需要向你的团队或一组利益相关者分享你在练习中的收获以及其带来的好处。这可能是通过一次演讲、一次研讨会或一系列你在该主题上的演讲来完成。
请让那些在第二步中支持你的人帮助你陈述你的观点。
目标是说服团队你们刚刚经历的过程很值得，并让团队支持将这个架构决策过程融入到他们的日常工作。
为了帮助团队改变行为并使其更容易接受，你可以建议先进行一个“试运行”，让团队先实施该流程一段时间，然后重新评估并确认该流程是否真的有帮助，还是仅仅让事情变得更复杂了。
关键是一步步地引入这些变化，而不是要求对团队的工作方式进行全面的改变。这样做很可能会导致对新流程的抵触情绪。
团队成员可以从这里开始：
- 下次有人需要对解决方案、系统、应用或任何其他具有足够技术或架构影响的事物做出架构决策时，记录一个基本的决策矩阵。
- 使用该矩阵以便与团队其他成员讨论解决方案和各种选项。
- 将最终决策记录下来，形成架构决策记录（ADR）。
为了方便团队的工作，你可以自愿帮助促进架构讨论，架构讨论将源于决策矩阵。如果你们公司有架构评审委员会，可以在该委员会中进行，或者也可以安排在其他会议中。
你还需要确保团队，我会一直在他们身边，引导和支持他们。这对新流程的成功实施至关重要，而新流程是团队运营的一部分。
摘要许多组织都有简化技术及架构决策流程的迫切需求。很多时候，这类决策根本没有相应的流程。缺乏这样的流程或流程无效会导致混乱、错失信息以及增加风险。
此外，这还会导致软件工程师、架构师以及其他技术和非技术人员在做出或依赖这些决策时产生决策疲劳感。
没有一个清晰、有效且可重复利用的框架，决策过程变得耗力且低效。技术决策者发现自己陷入反复的争论、不确定性及日益增加的操作风险中，而不是推动前进。
未能解决这一问题的组织将失去宝贵的时间，面临不必要的复杂性和灵活性下降的问题——更不用说极有可能忽视关键的架构考虑，从而带来严重的问题。因此，精简且透明的决策过程对组织的成功至关重要。
这个过程有几点需要注意的，
- 将技术决策过程变得可见且结构化，通过记录架构决策矩阵，该矩阵重点关注每个选项的关键方面。
- 利用该矩阵通过架构审查委员会或其他类似论坛来推动架构讨论。
- 决策作出后，记录为架构决策记录。
这篇文章提供了一种简单且容易接受的方式来实现这样的流程，而无需对组织做出大规模的改变。它涉及为一个特别需要架构决策的领域构建一个矩阵，然后将该矩阵与团队分享。最终，建议通过“试运行”的方式实施该流程，只需花费最小的精力。
这种方法的好处是：
✅ 减少阻力感 — 小改动更容易被大家接受
✅ 展示快速成果 — 保持动力
✅ 人们开始对这个过程建立信任
如果你正打算成为一名IT或软件架构师，或者你已经在这一角色中想要更进一步，你可以看看我写的一篇相关指南。它叫 解锁软件架构师的职业道路，我写这本书的目的是为了帮助那些希望在这个角色中取得成功的人，成为一个全面的资源。
共同學(xué)習(xí)，寫下你的評論
評論加載中...
作者其他優(yōu)質(zhì)文章
