每一项行动都是战役决策者根据战场上瞬息万变的情况做出的决定。有时候，影响战役格局的可能只是一个看似微不足道的细节，例如，准确的情报或者无法预报的恶劣天气。采购管理软件开发架构也是如此。在构架软件系统时，一个细节上的失误，可能会导致巨大的软件开发成本。我见过这样一个故事：在一个持续型的大型项目中，一位软件架构师，为了模块之间的解耦，决定使用ID作为模块接口的参数。他希望所有的模块，以最保守的方式封闭自己，甚至不愿意公布这些模块所使用的对象模型。基于这个想法，一个长整型看上去很理想。

于是他这样做了，而且还把这一原则推广到任何需要解耦的地方。结果呢？由于这些参数，必须要访问数据库才能获取相应的信息，随着采购管理软件开发系统规模的不断增长，一个业务操作竟然产生了成百上千次的数据访问。这意味着什么呢？意味着系统的性能将急剧下降，意味着性能调优的巨大开销，意味着升级的困难，意味着模型之间沟通和转换的不便。 

所以，使用ID来解耦，是一个设计上的失误。类似的设计失误在软件架构设计中数不胜数而这些失误，对于软件开发的影响是非常巨大的。因此我的想法是，一个成功的软件架构师应该像战役指挥官一样，善于用自己丰富的经验来规避一切后果严重的错误决策。

你也许要问，谁才能知道哪些设计是错误决策呢？要避免这样的错误发生，是否要靠一个决策委员会来投票表决呢？相信我，这些疑问是真实存在的。事实上，很多软件组织的高层管理人员都这么想。这些承担着经营风险的管理者，遭受过一次或多次不成功的项目。他们听到过来自各方的很多抱怨，他们知道问题出在软件架构上，可是，他们不知道该信任谁。在迷惘中，这些采购管理软件开发管理者不再尊重某一个人，而是寄望于一个团队来决策。这不是一个好的想法，问题因此变得更加严重。在第5章中，我们会详细讨论这个话题。在我看来，架构设计是大连财务软件开发中最有趣的工作。这项工作，需要的形象思维能力多过逻辑思维能力，需要的激进创新能力多过循规蹈矩。