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

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

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

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