建筑师

2003年8月14日

当人们使用“软件架构师”这个词时,他们是在借用建筑行业的隐喻来帮助人们理解架构师的角色。具有讽刺意味的是,这样做反而误解了建筑师的实际角色。

软件架构师被视为首席设计师,负责将项目中的所有内容整合在一起。但这不是建筑师的工作。建筑师专注于与想要建造建筑物的客户的互动。他将注意力集中在对客户重要的方面,例如建筑布局和外观。但建筑远不止这些。

特别是,建筑师不负责建筑物的结构完整性。那是结构工程师的职责,比如我的妻子辛迪。建筑师会请结构工程师来让他的建筑物屹立起来 - 通常,到这个时候,已经太迟了,无法做出改变来使结构更有效率。建筑物还需要电气和机械工程师,建筑师的初始角色也会带来同样的后果。

然而,尽管建筑师是团队中众多专业人士中的一员,但他却是负责与客户进行所有沟通的人。建筑师在大学接受过概览培训,并从所有需要设计建筑的学科中积累了经验,然而,他不可能在没有其他学科的输入的情况下代表所有学科。

鉴于对客户互动的关注,我认为软件开发中最接近的等价物是用户界面设计师。虽然我不信任这些隐喻,但这个隐喻确实有一个有用的推论 - 将架构师置于工作负责人的危险。最近的一个例子是,辛迪被叫来为一家酒店做结构工程。在她开始这项工作时,她意识到建筑师的布局需要一种特定的框架形式。稍微不同的布局可以采用不同的框架方法,从而将结构部分的建造成本降低 30%。建筑师拒绝了这种改变,因为他的建筑设计已经得到客户的认可。

由此得到的教训是,如果我们让架构师或用户界面设计师负责客户关系,那么架构师必须与其他专业人士有效沟通。我在与其他优秀的用户界面人员合作时发现的一个问题是,他们没有考虑到不同用户界面方案的成本。当这些成本是由更深层次的技术问题引入时,这一点尤其明显。戴夫·赖斯喜欢指出,应用程序的并发性和锁定策略不能与用户界面体验分离。然而,很少有用户界面人员了解这些问题。他们也不需要了解,只要他们能与那些了解这些问题的人有效合作 - 与典型的建筑师不同。

关于建筑师隐喻的最后一点思考。迈克尔·波兰的《我的家园》一书中贯穿始终的一个主题是建筑师和木匠之间的冲突。波兰描述了建筑师如何总体上赢得了控制建筑设计的斗争。遗憾的是,他指出,他们通常是工作中收入最低的熟练工人。软件架构师:小心你所希望的!