另外一个角度的架构师

架构师要作什么？

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

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

 

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

首先分析你的领导

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

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

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

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

接着分析你的团队成员

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

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

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

 

架构设计要思考的问题

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

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

Who：为谁设计？

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

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

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

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

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

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

 

总结

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

 

----------------------------------------------------------------------------------------------------

注：此文章为原创，任何形式的转载都请联系做者得到受权并注明出处！
若您以为这篇文章还不错，请点击下右下角的推荐，很是感谢！本文已独家受权给脚本之家（ID:jb51net）公众号发布！