如果建筑师错了怎么办？

您最可能知道我对软件项目中的架构师角色的看法，即由独裁者决定所有技术决策，并对最终结果承担全部责任。 我写过关于它的文章，甚至给出了一个任务谁是软件架构师？ 在2016年的BuildStuff。但是，您可能会问的一个显而易见的问题是：如果建筑师错了，会发生什么？ 这是否意味着整个项目都有失败的风险？ 让整个团队对结果负责而不是只有一个故障点不是更好吗？

这个问题确实很明显。 只要独裁者很聪明 ，独裁者就是一个很好的管理模式。 首先，这意味着具有以下能力：1）分析现实情况； 2） 收集所有可用的不同观点； 3）找到最佳选择，而将个人情感放在一边。 有多少人真正可以做到这一点？ 没有 很少。

其他人很可能会滥用权力，变成一个坏的独裁者，他不听别人的话，不注意不同的意见，并根据个人感觉做出技术决定。 有多少这样的软件架构师？ 所有 许多。

解决办法是什么？

我们如何首先摆脱独裁者，让团队决定什么是正确的架构呢？ 我们如何用民主取代专政，让软件开发人员以某种方式投票 ，这样就不会有单点失败？ 他们都将对产品负责，当产品损坏时，他们将全部有罪。 对？

错误！

团队责任是团队有史以来最可怕的错误。 所以不行！ 没有投票，没有民主。

比什么

想象一个真实的项目，架构师决定使用MongoDB（NoSQL数据库）来持久化用户付款。 这是一个有问题的决定，因为从传统上讲，关系数据库被认为是财务数据的更好选择。 但是，我们知道建筑师是独裁者，我们不应该争论。 我们不能告诉建筑师这个决定是错误的。 此外，我们不应要求建筑师说服我们。 做出决定。 完成。

我们能做什么？

我们可以回想起，架构师唯一真正的老板就是需求 。 架构师可能不会听我们，听开发人员，听客户，听任何人。 但是要求是无可争议的老板。 需求文档中是否提到有关数据库选择的任何内容？ 最有可能与此无关。 因此，建筑师将所有事情做对了。 要求说，付款必须持久且必须保持。 这些要求要求系统每秒处理多达一百笔付款，而且确实如此。 那么，错误在哪里呢？

好吧，我们只是觉得选择MongoDB是一个坏主意。 只是直觉。 但是也许我们错了，而建筑师是正确的？

为了使情况更加明确并解决冲突，我们必须修改需求文档。 我们必须说，此特定决定还需要其他内容。 假设，我们添加以下行：

每个第三方产品的选择必须基于至少四个替代方案的多因素分析。

一旦该要求条款获得批准，架构师将不得不改进产品文档。 必须对MongoDB，PostgreSQL，Oracle和其他一些数据库进行分析。 将定义一些选择标准，并且架构师将提供一些数字，以使MongoDB的选择看起来合理。

完成后，架构师的意见将变成数字工件，其中可能存在缺陷。 存在多少缺陷以及我们很快发现它们成为管理问题，相对容易解决。 我们只需要几双眼睛就可以看一下这个工件，并告诉我们这是怎么回事。 例如，我们可以请团队中的某人审查分析并告诉我们出了什么问题。 或者，我们可以从市场上雇用非常昂贵的人，但是却是数据库管理领域的专业人员。

一旦报告了缺陷，就必须由架构师以某种方式解决它们。 如果事实开始与事实相违背，要么必须改进分析，要么必须更改决策。

项目中的风险承受能力越低，我们需要更多的眼睛来审视建筑师所做的决策。 如果质量非常重要或架构师的专业水平值得怀疑，我们需要记录更多决策并进行更频繁的审查。 这是一个简单的数字游戏。 如果架构师是完全值得信赖的，并且该项目并不昂贵且只是短期的，那么我们只要让架构师做他想做的任何事情即可。

另一方面，如果架构师是初级人员，并且该项目对我们非常重要，则我们必须要求对大多数技术决策进行记录和分析。 我们必须组织对这些文件的尽可能多的审查，甚至邀请独立专家 。

因此，总结我的观点，我们不能指望建筑师是能够解决所有问题的专家。 另一方面，我们绝不能以民主投票取代建筑师。 两种想法都是错误的。 正确的方法是通过定期检查来控制架构师做出的决策质量。

您的项目中是否有此类评论？ 如果没有，为什么不呢？

翻译自: https://www.javacodegeeks.com/2019/01/architect-wrong.html