这次给我的命题是“企业应用架构”。老实说我有很久没琢磨这玩意儿了，是过去几周发生的三件事让我重新思考这一主题，并将个人之见付诸下文。

　　第一件，是我和我公司一位IT大牛人的午餐谈话。他是一位在IT行业风口浪尖弄潮的大牛人，所以我喜欢经常和他交流，来扩充自己的大脑。在一次这样的自由谈上，当我们畅想未来IT前景时，我记得他懒洋洋地靠在椅子上，面朝天花板，说：“企业应用架构这种过时的话题，难道我们必须要讨论么？”

　　然后他便又开始妙语连珠，滔滔不绝地谈论未来“四海一家”的IT解决方案，我也间或对他的新颖观点表示由衷的佩服。

　　一周之后，我接到我一位CIO朋友的电话。她的公司最近完成了一套ERP系统的全球部署。这个项目的初衷是让整个公司使用一套统一的业务规则和横向的过程控制。现在看来，各部门及业务单位都忙着创造业务规则的本地化表现，也因此让ERP系统的初衷无从实现。她希望听到我的建议。我几乎脱口而出的是“看来你需要一套坚实的企业应用架构啊，”但是因为我那位IT大牛的嘲讽之语一直在耳边徘徊，我只是向她表示了同情和理解，并要她给我一点时间思考。

　　然后似乎是要刻意强化我还生存在应用架构的宇宙中似的，一家软件公司的技术总监请我评估他公司的一个应用套件。看起来开发团队为了业务着想，开发出很多实际上是功能重复的应用。例如，这家公司已经有了六套支付处理程序和四套客户注册模块。

　　在这一点上，我感觉冥冥之中，应用架构之“神”向我传达一个指示，需要我重新来想想什么是企业应用架构。

　　然后，在与这家软件公司开发团队的领导们谈了几小时，我脑子里对于应用程序架构有了一个新的认识，下面是我的结论：

• 我的那位IT大牛只是部分正确。如果我们的应用同质化程度很高，那么实在不必制定什么应用架构。例如，我所在的公司，我们从同一家供应商处获得包括ERP、CRP和BI在内的所有产品。也就是说，我们购买具体产品，同时也就购买了一套应用架构。

　　如果应用环境是异构的，那么一个统一的应用架构就很重要了，因为它能使设计和实现走向规范化。对于那位技术总监，一个深思熟虑的应用架构可以让开发团队免除为开发第七套支付处理程序而烦恼。对于我那位CIO朋友，一个被认可的应用架构可以避免任何本地化ERP系统的举措。

• 构建横跨多部门的应用架构，体现内在的融洽。例如，支付处理系统是一项可应用于企业内部多个部门的应用，构建这样一套应用的基础，便是横向能自如地跨越多部门。
• 尽量使用通用服务组件。当你在考虑横向架构的实现时，识别出一套公共服务层及其借口，并尽量保证其拥有长期的适应性。就好比我给儿子购买过的最好玩具，是Legos积木－只需几个常见的可重复组合，便可构建出千变万化的形状来。我儿子可以乐此不疲几个小时。

　　不同服务的通用、可重复性体现在哪儿呢？对我的那位CIO朋友，我们觉察到，每个业务单元需要做的事就是：下订单、递送订单及支付订单。那么可因此制定出一套标准应用基础和公共接口层，来实现这些逻辑以及在各应用间通信，然后将这一标准应用基础整合进企业应用架构中。如此一来，无数必须要另行开发的服务可以快速实现了，只需要利用标准架构提供的逻辑，下订单、递送订单及支付订单。

• 分清正常与异常，并利用特别流程慎重对待异常。很多时候，我们都希望自动化任何过程，包括异常处理过程，因此系统变得日益庞大，最终不堪重负。异常状况不是经常发生，何必不就按异常处理？所以，我的策略是，异常发生时就按异常处理，不额外制定标准“异常处理流程”。
• 灵活性最大的敌人是复杂。我的CIO朋友担心其ERP系统在本地化过程中失范，很有道理。如果每个业务单位和部门都有自己的一套ERP配置，那么过度复杂的系统将会毁掉开发ERP系统的初衷。复杂性不好表现在很多方面，系统维护/升级的开销增加只是其中的一个原因。在一个瞬息万变的市场经济时代，时间就是金钱。复杂度存在，业务敏捷性就无法实现。因此，一个良好的应用架构，关键就是简单、一致。
• 确保企业明白，一个横向的、简单的、使用通用模块并慎重对待异常的架构，才是好架构。因为，无数强有力的事实证明，好的企业应用架构必然有着稳固的质量，而稳固的质量源自上述特征。这一点毋庸置疑，从未有人就此与我争执（包括IT人员）。

　　那位公司的技术总监制定了一套试点体系，整合各种服务资源并力求标准化，结果是更多可供开发的资源投入到生产系统，创造了极具竞争优势的产品（绝不是什么第七套支付处理程序所能实现的）。我的这位CIO朋友与其业务部门紧密合作，制定了一套标准架构以尽量避免各种本地化差异。我也因此一直回避我的那位IT大牛，因为事实证明他那套企业应用架构的“过时”论是错的，我不想打击他。