合格架构师的目标管理

“一个系统的架构,做到如何才能算好呢?”明眼人都能看出,这个问题就是问系统架构的目标。其实这个话题已经和很多人讨论过。一个非常简单的开头,结果却可能是千篇一律的答案。

“将系统做到可维护、可扩展、可延伸等等...那么这个系统就不错了。”

这个答案是一个典型的程序员式的目标管理。可以看出,这是一个非常完美的目标。但我要说,这不是真正的目标。如果你正在作为一个架构师,在架构一个新的系统。我想问问你,你会如何描述你的目标呢?

我问过很多人,很多人,都是类似与上面的回答。

要回答这个问题,首先要回答架构这个工作要做什么?我想很多人都愿意同意下面的说法:

  1. 架构=高层次设计
  2. 设计=权衡
  3. 权衡=问题>>方案1>方案2>方案n=问题+选中的方案

说白了,设计就是确定方案、选择方案的过程。

那么,我们架构要做得好,

  1. 明确我们需要解决的问题列表。
  2. 针对问题,列出可能的解决方案列表。一定要多于一个方案。否则不是设计,而只是解决问题。

是的,到了这里,我们就可以回答一开始的问题,一个系统的架构做得好,就是我们问题的解决效果做得好。当然了,这里面的问题包括功能性需求,也包括非功能性需求,特别是非功能性需求这部分对于架构影响更大。

所谓架构得好,就是方案设计到位,方案选择合理!如果我们要开一个架构评审会,我们评审会的重点也一定是在这里。

以前我参加过很多架构评审会,但是到最好,都是在听架构师讲解UML的类图结构。当然了,这与国内设计方面的阶段有关,很多人对于UML的理解还不完全。但这显然有很多弊病。特别是评审的人,并不能保障对系统业务的理解,所以对于类图不是很感冒,最多对UML的绘图技巧提出一些建议而已,反而忽略了架构本身重点的评审。这种评审会是没有意义的。

再回过头来讲,架构师也只有搞清楚自己的设计重点,工作也才能有的放矢。这永远比那些盲目最求完美系统更能解决问题。一个好的目标管理,会让架构师至少在工作安排上做到合格。

有人问我,所谓的问题+方案的目标描述,是不是只是“可维护性、可扩展性等等”的目标细化?从语言上讲,确实有这个关系。但我强烈反对这种认知,这是一个完全不同的出发点,一个关注的自己的取向,一个关注的是问题取向。不同的出发点,也代表了架构师的架构意愿。

因为架构师,就是自身判断能力的运用者。而架构意愿在其中起了非常大的作用。因此,要做一个合格的架构师,就要从严格要求自己的架构意愿开始!

阅读更多
文章标签: uml 工作 扩展 语言
个人分类: 架构设计
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭