我的架构思想(四十八):附录 2

阅读数:16 2019 年 10 月 16 日 15:05

我的架构思想(四十八):附录 2

附二:谈企业软件架构设计

节选自 ZDNET 网站 2007 年 3 月对本书作者的专访。

企业实施过程中的架构问题,可以分成两个部分来考虑:一个是软件企业自身,另一个是工程的目标客户(有些时候它与前者一致)。基本上来说,架构设计首先是面向客户的,甚至在整个工程的绝大多数时候都面向客户。因为理解决定设计,所以让架构师尽可能早地、深入地了解工程目标、应用环境、战略决策和发展方向,是至关重要的;否则,架构师是不可能做出有效的设计来的。

架构设计关注于三个方面:稳定、持续和代价。

稳定性由架构师的设计能力决定。架构的好坏是很难评判的,但基本的法则是“适用”。如果一个架构不适用,那么再小或者再大都不可能稳定。因此进一步推论是“架构必须以工程的主体目标为设计对象”。看起来这是个简单的事,但事实上很多架构设计只是在做边角功夫,例如为一两处所谓的“精彩的局部”而叫好,全然不顾架构是否为相应的目标而做。

持续性由架构师的地位决定。如果不能认识“设计的一致性”,以及架构师对这种一致性的权威,那么再好的架构也会面临解体,再长远的架构也会在短期内被废弃。架构的实施是要以牺牲自由性为代价的,架构师没有足够的地位(或权威)则不可能对抗实施者对自由的渴望。通常的失败并不在于架构的好或坏,而是架构被架空了,形同虚设。

代价的问题上面有过一点讨论,但方向不同。这里说明的是,如果架构师没有充分的经验,不能准确评估所设计的架构的资源消耗,那么可能在项目初期便存在设计失误;也可能在项目中困于枝节,或疏离关键,从而徒耗了资源。这些都是架构师应该预见、预估的。

对于企业设计来说,上面三个方面没有得到重视的结果就是:迟迟无法上线的工程、半拉子工程和不停追加投资的工程项目。我不否认项目经理对这些问题的影响,但事实上可能从设计就开始出了问题,而项目经理只是回天乏术罢了。

最后说明一下,我认为目前大多数的企业项目都缺乏架构上的考量。大多数软件公司只是出于自身的需要(如组件化和规模开发)而进行架构设计。这样的设计不是面向客户的,事实上这增加了客户投资,而未能给客户项目产生价值。这也是我强调架构面向客户的原因之一。

评论

发布