合格架构师的目标管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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