Question

节选自《程序员》杂志 2009 年第 10 期同名文章。

EHM 不是一个用于实作的工程模型，它只是从某个角度分清了工程的一些环节而已。如同“牛屎图”一样，EHM 是一个思考模型。相较而言，EHM 更易于发现问题，而“牛屎图”更适于理清思路。如果非要从中找出个“更核心”或“更重要”的，那么在“牛屎图”中要以哪一个作为最底层的圈子也成了问题。所以不妨抛开“谁更核心”的问题，把赵善中先生 1 的模型、EHM 图以及“牛屎图”作为可以相互补益的图来看，这样就所得多多了。

一个软件产品，究竟是被“开发”出来的，还是被“架构”出来的，抑或是被“管理”出来的？这是一个争执不休的问题。一般人，尤其是技术出身者，会直接否定掉第三种答案。他们认为“一个软件产品不可能被管理出来”，它只能是被开发出来，而管理不过是这个过程中的官僚角色罢了。但什么是管理？管理真的就是今天命令你工作、明天要你汇报进度的那个人吗？是不是我们把一些个人的私怨——对某个拙劣的管理人员的不满或轻视——带到了我们讨论问题的语境之中？

开发、管理和架构三种角色，站在自身角度，都会认为自己应该主导软件产品产出。这种观点我向来持以理解而又置疑的态度。更渐渐地，我对所有类似“某个单一角色主导了软件产品产出”这样的观点都表示怀疑。正如高焕堂先生 2 所提到的，这更像是一个“三足鼎立”的局面。这种“鼎立”的局面是一个衡势，这意味着它的平衡是瞬态的，且总在平衡与不平衡之间。所以我的疑问是：这种局面对于软件的研发、项目的过程来说，是适宜的吗？应成为常态吗？

从组织学（而非单纯含义的管理学）的角度上来说，鼎立是组织的一种形式，是管理的一个施为目标，而不是管理本身。虽然我认为高老师所指出的“鼎立”的局面可能是将来的方向，但如何去组织这样一个组织，管理它，并在这一局面上产出软件产品，是更进一步的学问。

在《大道至简》一书中，我基本否定了对软件开发过程的管理：

“开发团队并不需要管理。或者说，在你没有弄清楚状态之前，不要去管它。”

同样地，我也否定了传统的软件产品的“产出”观念：“ 工程不是做的，是组织的 。”既然我们不能“管理”一个团队，又不能去“做”工程，那么我们该怎么办呢？在我跳出上述的三个角色之后，我得到的答案是：组织。

进一步地说，管理角色的任命、项目团队的结构等，都是在“形成组织”——这一过程中的产出和阶段性的决策。对于（泛义的）软件项目来说，没有一成不变的组织，也没有一成不变的模式。更进一步地说，在（具体的）某个软件项目中，组织的行为也处在变化之中。

我推崇高老师“以序容易”的架构思想，而这也意味着我上面的言论会有一个推论：必然以及必须要存在一个“无序”到“有序”的过程，即我们最终仍然会得到一些“组织模型”（以及管理、过程等模型），用以规划和指导实施同类性质的项目。我不否认这一状态和阶段性结果的必然存在，但我怀疑现在是否已经存在，例如某些工程界吹嘘的“模型”是否就是终极的银弹。

因此，回到赵老师的话题，在“工程实施”的语境下，究竟（现在）有没有确定的模型呢？我不置可否，唯只置疑。架构是工程中的推手吗？是推动的原力吗？我从架构这一角色的位置及权威性上看得到希望，也从这个角色所必备的能力涵养上看得到希望，但是推及到组织及具体的项目，架构角色真的有这样的能量吗？谁赋予了他调适组织形态、降低组织内耗的责任？如果他没有这样的责任，那么组织如何生存？如果组织不存在了，岂不是仍然回到了“皮之不存，毛将焉附”的问题上了？

1. 赵善中先生是“结构行为合一”架构方法的创始人，人称“SBC 架构之父”。阿拉巴马大学计算机与信息科学博士，先后任职于中华电信公司、GE 实验室、中山大学资管系。时任国际企业架构师协会台湾分会理事长。 ↩
2. 高焕堂先生是台湾软件架构设计大师，从事 IT 行业近 30 年，被称为“台湾 OO 技术教父级代表人物”。曾创办 MISOO 对象教室及《SoSE 杂志》，时任 MISOO 软件开发与管理顾问公司 CSA 职务。 ↩