另一个角度的架构师

https://www.cnblogs.com/kiba/p/9207064.html

架构师要做什么？

ADMEMS矩阵，明确介绍了架构师需要思考的问题，而在这个矩阵中，做完一个架构师最需要了解的什么呢？技术？业务？都不是，最需要了解的是你的领导，其次是你的团队成员。

如果你的领导是不懂且不放权的类型，那你的好架构要如何实现呢。如果你的团队技术烂的一塌糊涂，又如何开发出成熟的产品？看看ADMEMS矩阵，理论上是先上后下，先左后右。而现实中，应该是先右后左，先下后上。

 

看了ADMEMS矩阵，最重要的就是约束，最最重要的就是开发需求对应的约束。那么架构师要如何分析这些呢。

首先分析你的领导

1，  确定他是否能清晰的分辨出团队成员技术的高下，这个清晰很重要，要十分清晰。

2，  确定他支持你架构设计的力度，（强烈支持，还是设计的好就用不行就不用）

3，  确定他是否真的理解了架构的重要性，还是他只是为了给工作计划戴个好看的帽子，还是两者都有。

以上三点只要有一点不满足你的架构基本上就很难实现，为什么是很难而不是不能呢？因为团队成员足以弥补一些领导的能力不足。

接着分析你的团队成员

1，  你的团队成员能力差距是否过大。

2，  你的团队成员能力高的和低的比例是多少。

正所谓巧妇难为无米之炊，即使你再棒，也没办法一个人做项目。团队成员当然都是高手最好，如果是2：1也可以接受，如果是能力低的多，那就要看领导了，如果他不符合上面三点，那软件开发流程就只会是和稀泥式的前进。架构与否就不那么重要了。当成员和领导都是优秀的时候，那么在分析其他需求又有何难呢?

 

架构设计要思考的问题

一个软件架构师最重要的问题，就是他所设计的产品必须是满足客户战略规划的需求，能够帮助客户解决实际问题的。

这是理论上，或者说是书本上的知识点，现实中的变数太多。首先要考虑着三个问题，who,what,why。

Who：为谁设计？

你设计的架构是为客户设计的吗？你的客户理解你的架构的重要性吗，也许连什么是架构都不懂吧。如果你的客户理解，那么恭喜你，你是在为客户设计一套理想的架构。如果不理解，那么很遗憾，你并不是为你的客户在设计，你是在为你公司的领导在设计。那么你设计的东西就需要为他们讲解。记得，有时候领导比客户更笨拙。并且他们会要求不断解释那些1+1=2的问题。有些架构师太久不去温习那些基础，只是记得1+1=2，却忘记了如何解释，那么很遗憾你的架构将遭到怀疑。我记得以前带我的前行一位架构师和我说过这么一句话，“信则灵，不信则不灵”，这不是迷信，为什么呢?因为架构师要能把所有的东西都给领导和团队成员讲明白，那大家就都是架构师啦，不是架构师讲不明白，是对手听不懂啊。

What：要解决用户的什么问题？

性能低下?结构转换？可维护性差？领导面子？（一点不好笑，真的有公司这么做的）。

我见过一个公司，他们的产品还能运行，但改起来很难受，程序员天天抱怨。于是就请了一个架构师，目的有二，（1）修改产品结构，降低维护成本（2）使员工不要抱怨。结果当然是无疾而终了，新架构上不去，又折腾了好久。最后不愉快的离开。原因是什么呢？首先领导并不是全力支持他，这会导致什么结果呢？他必须设计出完美无缺的架构，并且拥有神一样的讲解能力，否则新架构永远是有风险的。而现在的程序还能运行，不可能去冒这么大的风险。由于这个强力矛盾的存在，那么其他问题也就应运而生了。至于性能低下，结构转换，可维护性差等等，这些技术层面能解决的问题就显得不那么重要了。

Why：为什么要解决这些用户问题？

提高用户体验？用户强制要求？合理化软件程序？为业务拓展做基础？首先要确定，这些真的是用户需求吗？还是程序员们和业务们总结出来的理想建议。如果真的是从用户那里得到的，那么恭喜你，对症下药，功德无量。如果不是，那就是事倍功半，褒贬不一。抑或在根本无法得到客户需求，那么你就只能摸着石头过河了，至于成败，就只能谋事在人成事在天了。

 

总结

其实业界很多架构师都是摸着石头过河的。又有许多架构师失败并不是因为架构和技术，只是没读懂领导的心。架构师首先要分析公司的现状，然后再设计，当然发现公司现状根本不可能完成架构时，那就要早做准备，不要等到最后被个黑锅离开。如果公司问题太多，新就架构根本是无稽之谈，那就着手于小分区的修改，这也是个长存之道。