一级建筑师 系统分析师_如果建筑师错了怎么办？

一级建筑师 系统分析师

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

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

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

解决办法是什么？

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

错误！

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

比什么

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

我们可以做什么？

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

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

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

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

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

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

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

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

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

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

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

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

一级建筑师 系统分析师