另一个角度的架构师

架构师要做什么?

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

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

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

首先分析你的领导

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

2,  确定他支持你架构设计的力度,(强烈支持,还是设计的好就用不行就不用)

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

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

接着分析你的团队成员

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

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

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

架构设计要思考的问题

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

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

Who:为谁设计?

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

What:要解决用户的什么问题?

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

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

Why:为什么要解决这些用户问题?

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

总结

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

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

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏顾宇的研习笔记

微服务实施常被忽视的 5 个难点前言如何解决这些问题

笔者从 2013 年加入 ThoughtWorks 至今共 4年时间。在这 4 年的时间里,我分别以 开发人员, DevOps 工程师、DevOps 咨询师、微...

9010
来自专栏SDNLAB

中国电信胡杰:边缘注智,运营商政企网关开启“万物智联”新时代”

中国电信北京研究院物联网和互联网+研发事业部总工程师胡杰为我们带来主题演讲“边缘注智,运营商政企网关开启“万物智联”新时代”。

10710
来自专栏EAWorld

数据质量问题是“技术”问题还是“业务”问题?

? 是不是感觉漫画中的场景很熟悉?没错,这种场景几乎每天都在企业中重复上演。 一、数据质量问题的危害 当前越来越多的企业认识到了数据的重要性,数据仓库、大数据...

45290
来自专栏互联网数据官iCDO

电商流量分析实践:如何根据基准,制定和合理分析KPI?

译者:陈明艳 审校:李晓艳 本文长度为2752字,预估阅读时间10分钟。 摘要:作者通过实例演示,如何根基情景基准设定KPI。 作为一个数字营销人员,我深...

26250
来自专栏人称T客

创业公司生存警示录:实现增长必备12项法则

T客汇官网:tikehui.com 撰文 | 徐婧欣 ? 1. 增长团队「有责任衡量、了解和强化使用产品及业务的用户流。」「财务团队则要负责理解和强化公司的资金...

36650
来自专栏陈树义

优秀程序员具备的高效习惯,你具备吗?

我在《聊聊阿里面试的三个层次》中说到阿里的面试要求,其中有一个读者看完觉得很困惑,觉得这些知识点平时都用不着,如何去学习这些知识才能保证学习质量呢? 我有个迷...

42880
来自专栏新智元

【深度】亚马逊Alexa称霸CES,语音计算平台仍面临这5大技术挑战

【新智元导读】亚马逊的Alexa在CES上的大获成功让关于智能语音的话题再次被业界广泛谈起。低调的亚马逊似乎已经在这一潜力巨大的市场上完成了布局。大家的共识是,...

41580
来自专栏大数据挖掘DT机器学习

【总结】梦想与前行-一名数据人的自白

前段时间看微博话题讨论有些迷茫,有些已经被同行确认无疑的观点竟被反复强调,比如”数据挖掘/分析要懂业务”、”产品是数据价值变现的一条有效渠道”,观点没错,但听多...

29240
来自专栏SAP最佳业务实践

MBA管理:敏捷项目管理的关键

头脑敏捷的负责人会预见项目执行中的不确定性变化,并灵活应对,而不是固守原来的计划。实践中,他们深知预估性判断的局限性,因而更信赖自己的变通能力,即根据变化对项目...

35860
来自专栏Java学习网

10年学到的编程经验总结

10年学到的编程经验总结 我作为一个web开发者的旅程始于2000年,那时我还只有21岁,我依然可以清楚地记得那些日子里激荡在我内心的感觉。如果一定要找一个词来...

28190

扫码关注云+社区

领取腾讯云代金券