业务开发平台与SOA的统一论.doc

　　数字应用的世界里应该都是一个个的小球，代表着一个个简单的功能，几个小球组合起来，就是一个超级无敌的变形金刚。我们程序员学设计模式、学架构、苦练抽象/接口/范型、搞平台，终究敌不过让人想拿棉花当板砖撞头的用户大帝。我们盼啊盼，盼了CORABA，盼来了EJB，盼来了COM+，如今我们又盼来了SOA，一个个设计精巧思考成熟的组件模型体系。但是，我们的胜利号角怎么还是没有吹响呢?我们怎么还处在石器时代照着石头磨刀呢? 　　让我们来仔细分析分析，用范师傅的话说就是捋捋，否则容易乱了。 　　用户往往会这样告诉我们，我要看到这样的数。 　　我们的项目经理一听，哦，你要的是一张报表。但报表的数据需要录入才能统计出报表啊。嗯，再调研录入什么。客户就会说我们平时手工是怎么计算这些数的，这些数的原始凭证是怎么产生的，是什么人填写的，说了一大串，项目经理猛记，这就成了流程，嗯，咱们软件也这样处理。再跟客户要一张空白的原始凭证样纸，就OK了。有输入，有统计，有业务处理流程，齐了。回家跟程序员说清楚，开发去啦。 　　嗯，没几天开发出来了，用户一用，嗯，不错，大致是想的那样子，但这里需要再改改，不好用。 　　没关系，没关系，这块好改。 　　一个项目就这样来回几次就验收了。 　　但我们并不想一次编程一次运行啊，怎么也得多卖几家，反正软件也开发出来了，不卖给其他客户也就在那儿搁着。于是四处借机给其他客户不断推荐、影响、报方案。客户一看，嗯，比较符合我们的需要，就买单了，但是需要这块那块修改一下。 　　修改一下?程序员头大了。这可不是一下的是，自己写的代码自己知道，自己怎么会在过去知道现在的事情呢?这个从来没有想过啊。但是客户的理由也很充足：“因为我们是这样这样的，所以我们的业务是那样那样的”。全程听完，嗯，也有道理。客户有不知道你过去的代码的来龙去脉，不就是多个查询么，不就是多显示个字段么，干吗说难呢，干吗说需要很长时间呢，干吗说改动很大呢?不理解。谁也理解不了，包括老板。 　　改呗。但是这个客户和过去的那个客户，在细节上有共性也有差异，怎么兼容这两家，毕竟以后还都要持续维护升级啊，如果维护两套，发现了BUG，这不得好多个版本进行修改和发布么?即使做成了DLL，代码也得改变，只不过不需要整个系统都编译更新罢了。没办法，增加配置参数，如果是1就那样处理如果是0就这样处理。 　　第三个客户又迎来了。完，絮絮叨叨说了一大堆，就是说，有个流程处理上和现有软件做法处理有矛盾。再增加配置参数呗。 　　代码中非常多的if..else，软件配置参数中非常多的配置参数，由于实施了客户多了，软件修改的多了，谁也记不起来为什么要这样修改，是应哪家客户的需求作的改动。尤其参数多了，而且不同的参数会影响多条业务处理流程，如果有9个参数，就如同有9个开关，这样开开关关就有很多种排列组合，最后软件走出来的业务流程连实施人员都不清楚该怎么配置才能适合当前这家客户。软件太难用了，咱们的软件太难用了。太难用了。 　　销售、实施、培训、支持，都在抱怨咱们的软件太烂了，根本卖不出去，卖一家就等于骗一家。 　　不行，这样做怎么能行呢，我们要重新完全开发一版，这次要设计的好好的，考虑的全全的，考虑全面了，我们这次开发出来的就一定很OK的。老板下了大令。 　　完全新开发的一版出炉了。给老客户升级，爽啊，很多流程通畅许多，到底是考虑全面了，这次有了很多的业务经验积累，都是过去咱们对客户业务理解不精深产生的问题。 　　欢喜啊。但没过多久，高兴不起来了。因为签到了新的客户，我们想塌脑子想出了99种各种业务情况，但是客户却属于第101种。见鬼了，怎么每个都是一个个案。是我们运气不好?我们可以说我们是全国最优秀的软件了，我的这个业务流程是聚集了全国几十家优秀成功案例客户经验开发而成，是最先进的最综合的。但客户说：“我这个需求能处理吗?”。一句话，干倒。 　　于是，新的一轮抱怨、压力、焦急、思考开始。有人半路跑路了，有人还在琢磨平台、设计模式、最先进的业务模式、最先进的盈利模式。 　　见鬼了。我们的小球哪里去了?我们讨论了大半天，我们的小球哪里去了?我们的SOA呢，我们的COM+呢，我们的MVC呢，我们的框架呢?我们为什么没有用SOA呢?我们为什么没有用EJB呢?我们为什么没有用COM+。 　　于是新一轮的完全版本开发又开始了，能有人走入这个循环的都已经是珍稀动物了，大量的人不会经历这么多完全重新开发，因为大量的IT公司被熬倒了。 　　我们这次不仅有101种业务场景，我们更有200种业务场景。这下大家该满意了吧。我们过去失败是由于我们没有平台没有SOA，现在我们用了，这下我们该成功了吧。这次我们可是下大血本啊。 　　于是，积累了数年上百家客户的200种业务场景被装进了OA办公系统平台中，各种MVC、持久化、工作流