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

    数字应用的世界里应该都是一个个的小球，代表着一个个简单的功能，几个小球组合起来，就是一个超级无敌的变形金刚。我们程序员学设计模式、学架构、苦练抽象/接口/范型、搞平台，终究敌不过让人想拿棉花当板砖撞头的用户大帝。我们盼啊盼，盼了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种业务场景被装进了SOA平台中，各种MVC、持久化、工作流、表单设计器，应用尽有。

    见鬼，眼球掉地，第201种业务流程！需求这个大虫怎么打不死打不尽呢？

    好不好改？回答曰：好改，我们都做活了，可以直接动态修改不需要编译就OK的。

    NO，NO，NO。我要的是调整调整就OK的那种。回答曰：这个真的不行。

    为什么呢？hang~~~。

    一顿解释。无奈，继续重复轮回。（难道还要第四次完全重新开发？）

    让我们回过头来，看看我们到底错在哪里了？我们什么都做了，怎么还是错？难道世间本无解？

    我们再把开头的一段话放到这里：数字应用的世界里应该都是一个个的小球，代表着一个个简单的功能，几个小球组合起来，就是一个超级无敌的变形金刚。

    我们总是走的太远，以致常常忘记了为什么要走。

    大家再想想车（我们总是拿汽车做工业化流水开发最好的案例，我们这次就专门拿汽车做个好好的对比）。基本款的，基本款自动挡的，各种排量的，各种颜色的，自动挡或手自一体的，豪华款的，带GPS的，带六气囊的，带到车雷达的，等等等等。出一款车，往往能细分出多达十几种车型。就算你是个汽车改装爱好者，你想把这十几种车型每个优点都拿出来然后整一台总优秀的车，你都整不出来。很好理解，杨贵妃的眼睛西施的最貂蝉的鼻子昭君的眉，PS出来的肯定不是美女，而是一个四不像，怎么搞都变扭。

    软件如车，也如PS。

    真正的组件世界，大家好好看看facebook现在的插件思想，大家剖析一下facebook给这些插件提供了什么？

    我们创造了无数的框架，为了解决一个又一个的问题。我们总是希望提供最高的灵活性来应对未来的未知。我们做的越多，反而我们限制的越多。我们为了做的最少，反而我们后来无从下手。

    从统一论来看：SOA、业务开发平台、Open API、插件容器、javascript、URL、mashups，皆能合一。我历经架构、平台、中间件、组件、框架、各种重型设计模式与重型企业级大词，作为我个人，我仅仅只看到这一个观点。有时候，你负的重了，从反方向看，你会立马超然，原来风景还可以这样看。

    谁是未来的架构哲学，谁是未来的盈利哲学，谁是未来的销售哲学，谁是未来的关系哲学？

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友