关于架构师(Architect)在这样一个以信息技术为主导的世界中是怎样的角色,总是有着不同的说法,甚至架构师自己还常常泾渭分明地区分自己是软件架构师还是硬件架构师或者应用架构师。只有一点是肯定的:这是一个非常“崇高”的名词,一旦使用便让人充满崇敬的赞誉;不是一般的人都觉得自己可以无愧地面对这个称号的。
如果将每一个系统都看作是上帝创世一般的世界,就像早期的计算机科学家那样,在今天已经是不可能的了。今天的系统与其说是上帝创世,不如说是从繁复的需求和无尽的限制(前面两个形容词换一下位置依然正确,Sigh)中去试图抽象一个模型,以期尽可能的反映一部分人的理想(或者幻想、梦想、空想等等)。于是乎现在的架构师,作为一个在系统构建方面的集大成者,可以说是这样一个构建和抽象过程中的哲学家。因为他需要解决的问题,不再是具体的设计和构建,而是如何去设计和构建用于设计和构建的具体行为,也就是“元设计”。
传统意义上,架构总是和设计联系在一起,就像设计和开发联系在一起一样。不过今天无数人已经知道,设计和开发就像设计师和工人一样不同,自然架构和设计也不是一样的工作。当一个人在开发中不断反思,就会上升到设计;如果继续对设计进行反思,结果不是所谓的“高层次设计”,而应该是“架构”。往往现在的架构师等同于执行高层次设计的人,后面我们会发现,他们是完全的不同。
因为架构师要做的事情,是设计“应该如何设计”,甚至是思考和设计“应该如何执行项目中的所有过程”。这是一种彻底的抽象,一种对设计本身的形而上学;和哲学不同之处在于,哲学面对的世界是先验存在的,于是哲学家们总是试图构建一种认识“认识世界的各种理论”的知识,即知识的知识;而架构师的空间在于,他有机会构建一个“构建世界的各种理论”。于是架构师应该做的,不是画出那些高层次的系统框图,而是说明应该如何画出这个系统的各种设计图——并且证明(说明)这一系列方式是正确的。
我不是说架构设计的理论和哲学理论是完全一致的,不过就算是举出几个简单的例子,也足以类比出两者之间惊人的相似。近代早期的两个著名哲学流派大陆理性主义和英国经验主义,前者假定世界是可以精确的认知的有一个确定性的答案,后者则怀疑甚至否认一切既存的理论甚至存在本身。如果我们看待系统构建过程中的两种主要用于指导设计的方法论,我们当然可以把那些假定有一个正确的设计,这个设计来源对于需求的逐层形而上学的抽象最后落实为一个自上而下的唯一正确的设计然后付诸开发的态度,视为当然的理性主义模式;而把那些假定需求总是不可预测,从而先实现一部分然后再边做边慢慢抽象甚至不再抽象设计的家伙视为经验主义者。显而易见现在大多数架构师都知道做一些基本的抽象(例如画一个高层次架构图)然后迭代地不断完善,那岂不就是黑格尔从肯定、否定到否定之否定的过程么(如果考虑到这是一个螺旋上升,而不是终结,我们就已经进入马克思主义哲学了)?当然敏捷开发就像存在主义哲学颠覆黑格尔一样颠覆着传统模式,他们常常说,代码的存在就是一切。
我们只要在此了解到,哲学家认识世界的过程,和信息系统构建过程中认识需求的过程几乎是一致的,并且在构建系统过程中这种认识是必须的,就知道这是任何一个系统构建项目都无法逃避哲学问题。而且这些哲学的思考结果还会得到真实构建的检验,虽然这个过程中也多了一些创造性的空间——因为系统不是必须和需求一样,我就常常用设计去改变需求。
一定程度上,所谓方法论就是这里的架构哲学。然而方法论这个名词现在被用烂了,这个本来用于描述“关于方法的方法”的名词常常退化成为一种方法本身。GoF的设计模式被奉为圣经仍然只是方法而已,方法的方法只有“面向对象”才有资格冠冕。同样面向过程就算被抛弃许久,不可否认这也是一个曾经主导一切的方法论,或者说设计哲学,因为根据这种哲学,计算机世界就是对人类具体行为的抽象(面向对象则是按照“世界客观本体,和本体的能动”进行抽象设计过程的方法)。
我可以坚信的是,每个自认为胜任架构师的人都有自己的分析和设计哲学,问题在于他们多大程度上清楚的知道自己平时真的在干些什么架构方面的工作,以及贯穿他们一致的架构哲学到底是什么。所以与其做一个迷茫的被推到架构师位置的设计师,不如好好细细审视架构哲学本身。
这里唯一需要另行解释的是“应该如何执行项目中的所有过程”中,是否包括了项目管理。可以是,可以不是,就算不是,也不能否认架构师和项目管理之间纠缠的关系(难怪通常架构师和项目经理必须是同性呢,开个玩笑)。《人月神话》中提到的以架构师为核心的项目团队,今天有多少人还会相信?专业的项目经理概念已经是根深蒂固了。就像大概不会再有人说哲学家应当执政一样,但是从柏拉图的《理想国》开始一直就有哲学王的概念在;眼下让一个架构师去思考项目管理中的具体问题已经纯属浪费,我们往往也假定项目管理哲学已经由一些另外的人解决了,于是架构师虽然仍然应该关心一下项目管理并且有针对性的帮助项目经理的管理和系统构建本身相融合,不过最重要的仍然在于“定义和指导”项目中“(比较)没人性”的“(看上去是)科学”的那部分工作——再次重申,架构师不是去做具体的设计,虽然不是不可以;但架构师是为具体的设计设计好整个过程。