说说业务平台这件事

       今天看了国内号称最大的业务平台产品的白皮书，也有朋友见过他们公司的产品演示，反应是巨牛无比！以前写过一篇Blog，在回复中涉及到业务平台这东东，引起了gigix和o6z的一些看法，后来我就一直在关注这种东西。

       目前听说两个产品，见过一个产品。

       今天看到的这家公司可谓是理论与实践并重，ppt和白皮书都很有煽动力，如果我是客户我基本就投降了，不过我是搞技术的，多少有些怀疑态度。

     首先，其引用了Brooks的话，我想这话大家都很认同：

   Brooks指出：所有软件活动包括：
   根本任务——打造构成抽象软件实体的复杂概念结构；
   次要任务——使用编程语言表达这些抽象实体，并在时间和空间内将它们映射成机器语言。

   接下来其论证是：由于技术是软件活动的次要任务，而大多数企业级软件开发都是用编程语言code出来的，也就是都是面向那个次要任务，即使你把次要任务做成满分，也无法解决根本问题。

   在有限时间里，你既要解决次要问题，又要解决根本问题，从表面上看一定不如只解决根本任务好
   根本问题是一样都需要解决的，从表面上看，谁解决次要任务的时间短，成本低，谁就更好。
 
   之后，是证明其平台能力，什么类型的业务平台都能装配起来，并且其应用行业之广，使用单位之多，让人叹为观止。也可以说，这种方法确实不是纸上谈兵。

   其还强调了其思想不是搭积木，而是使用插件体系，把用户需求变成插件。这有点ESB的意味，但是，那个插件谁来编写，而这个插件里面的东西是什么呢？

  
   我比较关心的问题是：
   1、其如何解决企业级开发的重要、复杂问题。比如事务分割（一个原子性遇到复杂业务都是很难设计的），锁机制的设计（我在工行信息中心工作的同学天天受者DB2加锁的折磨）。莫非平台可以给我们一个万能的策略？某公司的基于流程自动配置的OA系统，就存在严重的事务并发问题。

   2、其如何解决企业级开发的重要、复杂问题。生产型企业系统的核心复杂性在于业务逻辑，而非工作流，莫非这样的系统只是填单，审批？而业务逻辑一定是个性化的。这种业务逻辑的复杂性，使不使用平台都要手工编，那么是不是在平台下更难编？

   3、其如何解决企业级开发的重要、复杂问题。DDD那本书强调企业核心复杂性是业务复杂，而解决之道是DDD，对此我颇为同意。我以为所倚思想及技术一定是OO。我看过的那个OA的流程定义，可以通过编写节点上的函数，来附加执行到那一步的业务（我觉得类似于JBPM的Action）。写些简单的小函数还行，如果是一个使用上千行代码才能实现的业务逻辑怎么办？（怎么可能有上千行的代码才能实现的业务逻辑？肯定是你的算法不优化。可惜，我做过的系统就是有那么复杂）如何测试这个方法呢？这个新添入的方法的事务如何控制呢？

   4、说说UI设计。企业级应用系统，不是简简单单填个表单就完事了，比如级联的下拉框（我们的界面需要5级联动，还要根据前面选择的数据向其他的标单元素填写数据），而且下拉框填充的数据是根据复杂的计算规则计算出来的。下拉框只是提供固定的几个选项的情况很少见，因为我们不是做OA，新闻站点，BBS。

   5、维护。我很担心前面提到的那个复杂的上千行的方法如何维护，或者我想错了，那个OA平台是那么做，用超牛的平台就不会这样了。或者你可能说，你不用平台开发，也可以把那个大方法拆成小方法嘛。这是我要说的第6点。

   6、使用平台是不是使简单的事情简单了，使复杂的事情更复杂了？

   或许是我多虑了，在观望，毕竟我现在也没用过。

        鉴于大家反复在寻求本文所指平台，本来已经在回复中写过，但是并未引起注意，所以在Topic中重申：

      我在这里讲的业务平台，不是J2EE这种底层的开发平台，不是ERP这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。

评论

46 楼 sofar1218 2007-12-22  

没有技术无关的业务平台，至少目前没有，不过可以说是限定领域的限定需求业务支撑平台， 比如电信BOSS，也就是你的技术平台足够（但不是无限）灵活，生命期足够（也不是无限）长， 足够（也不是随便找个人都可以）易用，可用到足够多（也不是无限）的行业。但是从哲学上这些因素中有些是矛盾的，比如要做到足够灵活通用，那么构件就要足够原子化，而装配过程就不会足够简单，非常复杂的装配过程难道不是编程？

也许有一天某物可以把元素周期表里的原子组装成一只猫。还是那句话复杂性不会消失。

业务需求也不是完全超脱于技术，新的技术普及同时也会唤醒更多的业务需求

飞机没有诞生之前，人类就渴望飞行，今天还没有海陆空通用的交通工具，也许以后有
，
足够灵活的技术平台升华（或者幻化）成一个业务平台。

足够健康的肌体才会琴棋书画 诗词歌赋。

所以只有技术平台发展到非常的地步，才会浮现业务平台（ejb也是一次尝试）.未来的路还长的很, 作技术的把技术整明白, 作业务的把业务理清楚, 两者沟通流畅,这是目前比较现实的

真正的趋势倒是分工越来越细,专业化越来越高, 万精油越来越不值钱

45 楼 liyong_2003_cn 2007-12-21  

http://www.iteye.com/topic/149882

44 楼 sslaowan 2007-12-21  

<p>

Godlikeme 写道

这种方法不能称作 结构化方法，是问题分解法（类似分治法），问题分解中如何解耦是核心问题，o6z所说如何分解为一些基元，解耦前提下再谈怎么组合还有意义。

</p>
<p> </p>
<p>        感觉就是老外辛辛苦苦几十年，您一句话回到解放前，自顶向下，逐步求精的方法，是结构化方法中的一部份，它先于结构化方法提出，在OO中也有，比如领域驱动建模，就是先从顶层设计，然后在从小的往上设计。自顶向下，自低向上，这是两种方法，而结构化方法和OO方法（编程范型发展史上最著名的两个里程碑）中包括了如何进行自顶向下，或者自低向上的一整套指导原则、策略、最佳实践、模式等。</p>
<p>        结构化方法和OO方法两大范型体系，不就是将如何解耦，实现关注点分离；如何增强内聚，形成原子这些经验，隐性知识转化为显性知识吗？</p>
<p>        从我的观察，老外和我们的习惯不同，老外喜欢把什么方法都写成八股文总结出来，起个名字，比如光迭代体系就好多名字，以至于有人问我，当初的原型法不就是迭代吗？这是当然的了。因为你做事情就两种方法，一种是顺序的，一条道跑到黑，不回头；一种是循环的，做一做，回头看看，修改修改，再做。显然做复杂的事情你不可能一气呵成，或者概率比较低，那么迭代法就是必然的。不过仔细想想，都是迭代法，有什么不同吗？当然有了，老外做研究似乎和我们不一样，光看看人家后面那参考文献就巨震撼，凡是引用的话全有出处。所以可以相信新方法中都是有很多不同的。所以才有了Ivar又出来一统江湖，提核心实践，把自己过去以过程为中心的思想推翻了。</p>
<p>        这部分和这个Topic没啥关系，不过我觉得也是有探讨的必要的。</p>

43 楼 Godlikeme 2007-12-21  

ronghao 写道

我是一个业务平台的支持者。我想说的是业务平台是有它存在的价值的。而它的价值恰恰体现在其对业务的理解上面，脱离开这个最基本的概念，我觉得都是扯淡。所以我一直对哪些所谓适用一切的平台很不以为然。而这种对业务的理解实际上能够极大的简化项目的开发。拿最简单的OA说事，OA里面最核心的业务就是发文和收文，这里面涉及到很多业务，比如说会签，比如说传阅、收回等等。你用JBPM来描述这些业务试试看，工作量大的去了。然而你用一些业务平台就能很轻松的解决这些问题。也就是业务平台要解决的其实是业务问题，而不是技术问题。至于说什么联动框、UI设计等等，你觉得是最重要吗？
至于O6Z所说的元子组合的开发方式，还比较遥远不是。

基本同意上述观点，比较贴和实际。
不要动不动就这业务平台、那工作流平台，都是营销术语，忽悠客户用的；
作技术还是踏踏实实把业务问题搞搞清楚，把技术掌握，灵活运用。做的多了对一些核心的、相对稳定的业务做抽取，这样的东西才有可能慢慢积累起来成为业务平台。

参考下 NetWeaver平台的介绍和定位吧。
http://www12.sap.com/china/solutions/netweaver/index.epx

42 楼 Godlikeme 2007-12-21  

gfh21cn 写道

  业务平台是业务开展一段时间的总结，是建立在现有的开发思想和平台的基础上，对现有的软件技术进行抽象化的一个层面，它的形状就像金字塔一样，肯定会丢失一部分的灵活性和功能性，理想的平台应该是解决约80%通用性的问题，但是保留一定的空间给予灵活，可以基于底层进行复杂的应用开发，有点像阶梯状，而不是完全的一个封闭的，阶梯形的实施模型允许通过平台构建快速的应用，同样也允许通过底层的原始API开发复杂的业务逻辑，上次在展会上有看到一家软件公司，宣传“不需要编写代码”，甚至无需专业人员，就可以完成公司的管理软件开发，其实，从现有的技术水平来看，是做不到的，纯粹是一种炒作。

  业务平台的出现其实是一个积极的信号，就是市场对于原先软件开发过程的缓慢、拖沓的不满，但是对于平台是如何的一个标准，尚还没有一个比较完整的标准，说一个工作流系统就是一个平台，我觉得那是片面的，毕竟企业应用不只是这些，它们只能解决了客户的一部分需求。现有的平台可谓五花八门，百花齐放，不过随着市场的深入，技术的进步，会逐步形成一些标准，市场也会逐步分化，开放的标准是一个必然的趋势。
  
   平台的出现，降低了成本和提高了效率，让用户从以前的两种选择（要么选择通用型软件，要么选择从头开发） 中有了第三条路。

 

针对引文提出以下问题：

业务平台是业务开展一段时间的总结，是建立在现有的开发思想和平台的基础上，对现有的软件技术进行抽象化的一个层面。
业务平台是针对业务的还是针对技术的？平台是一个什么概念？


平台应该是解决约80%通用性的问题。。。。
解决的是 “什么的” 通用性问题？？？

说一个工作流系统就是一个平台，它们只能解决了客户的一部分需求。
工作流为什么成为平台？什么是平台？解决了客户什么需求？？？

41 楼 Godlikeme 2007-12-21  

这种方法不能称作 结构化方法，是问题分解法（类似分治法），问题分解中如何解耦是核心问题，o6z所说如何分解为一些基元，解耦前提下再谈怎么组合还有意义。

40 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

to sslaowan 其实面向结构的方法，是和以前的业务分析方法相映衬的。可以说以前的业务开展，是以产品为核心，也就是最终的解决都集中于一个稳定的产品。而现今的业务，已经在过渡到以服务为中心，也就是去满足客户不断变化的爱好。这种爱好，你无法预先定义，也无法事后回溯（并非不存在定义和回溯的方法，而是过于昂贵，不适合生产）。在此情况下，面向结构的地方，自然不能取得很多的效果。

</p>
<p> </p>
<p>      嗯，我资历比较浅，还是学生，而我们的项目都不是做个稳定产品（您的意思是指Mircorsoft Office那类的？），都是企业信息系统，也就是你说的充满很多无法预先定义的东西的产品，从我自己参与的有限的四个项目（都很大很复杂）经历来看，从我对于OO需要解决的复杂问题的理解来看，我是对这类宣传中的平台持怀疑态度，而且觉得使用它会掉进一个你无法控制，甚至平台提供者也无法控制的深渊，最后死的很惨。</p>

39 楼 ozzzzzz 2007-12-20  

to sslaowan
其实面向结构的方法，是和以前的业务分析方法相映衬的。可以说以前的业务开展，是以产品为核心，也就是最终的解决都集中于一个稳定的产品。而现今的业务，已经在过渡到以服务为中心，也就是去满足客户不断变化的爱好。这种爱好，你无法预先定义，也无法事后回溯（并非不存在定义和回溯的方法，而是过于昂贵，不适合生产）。在此情况下，面向结构的地方，自然不能取得很多的效果。

38 楼 sslaowan 2007-12-20  

<p>

ronghao 写道

引用

你觉得用户体验不重要吗？或者用户要求提高一个在一个界面就能做所有事情的界面，那个界面大而复杂，不符合美学，但是那是用户需求，你觉得用户需求不重要吗？ 所以本文不拿OA说事，我已经说过很多次了

我说过不重要吗？我说的是最重要的是什么而已。另外，存在就有价值不是

</p>
<p>           有时UI会成为最重要的部分，而非业务逻辑，很奇怪的现象</p>

37 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

引用

结构化方法是个专有名词啊，没有什么“其实”之类的说法了吧。当然无论什么方法都会出现结构和行为两个方面，而结构化方法和OO就是对其考虑有先有后，可以看Rebecca J. Wirfs-Brock写的1989年写的Object-Oriented Design：A Responsibility-Driven Approach，开头就指出了先考虑结构会破坏封装，才提出了RDD。

结构化方法是一个专有名词，所以我才用面向结构的方法的说法来避开它。至于RDD仅仅只是一种早期的思考，现在的发展已经很远了。

</p>
<p>     嗯，其实你替面向结构，是否可以理解为对与RDD的一种否定呢？RDD是后来研究的基础，包括Larman提的OO原则，Evans的DDD，还有契约式编程，我觉得，面向行为（与你提的面向结构相对）才是主流吧</p>

36 楼 ronghao 2007-12-20  

ozzzzzz 写道

引用

在业务流程图中元素也是专有名词，那些文件，数据库，处理，判断之类的，我所谓节点是其中的处理。

元子就类似这些元素

这个概念总是理解的有些抽象，实际我们在工作流里对很多业务操作进行了管理，并可以复用和组装，我觉得有点类似的意思在里边。

35 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

我还有些意思你没理解到。如果他们宣传的平台确实存在，并且效果确实很大。那么对客户业务的影响将是巨大的，这个时候客户需求就会受到你的系统的启发，呈现爆发式的膨胀。而其这个业务平台的有效性越大，其膨胀速度越快，循环圈越小，从而造成平台自身越快失效。如果事情发展到极致，那么当你听说这个业务平台的时候，它已经死了很久了。 

</p>
<p>         我明白你的意思，你的意思是平台要随业务发展以适应业务。其白皮书中有个比喻，平台好比CD机，业务好比CD，不同的业务只是不同内容的CD，我的理解是，该平台承诺只要你别换成DVD，那就都能播。也就是说，其平台不需要因为你需求而频繁改动才能满足新业务的，要不然还要平台何用？</p>
<p>        然后你确定，以现在人类的生产力水平来看，这个平台上不可能有的，好比在唐朝，有人说我可以上月球上去，人家都会认为那人疯了。</p>
<p>       其实我的怀疑是在于此的，但是我资历浅，水平有限，不敢下这样的定论而已。</p>

34 楼 ozzzzzz 2007-12-20  

引用

在业务流程图中元素也是专有名词，那些文件，数据库，处理，判断之类的，我所谓节点是其中的处理。

元子就类似这些元素

33 楼 ronghao 2007-12-20  

引用

你觉得用户体验不重要吗？或者用户要求提高一个在一个界面就能做所有事情的界面，那个界面大而复杂，不符合美学，但是那是用户需求，你觉得用户需求不重要吗？

      所以本文不拿OA说事，我已经说过很多次了

我说过不重要吗？我说的是最重要的是什么而已。另外，存在就有价值不是

32 楼 ozzzzzz 2007-12-20  

引用

结构化方法是个专有名词啊，没有什么“其实”之类的说法了吧。当然无论什么方法都会出现结构和行为两个方面，而结构化方法和OO就是对其考虑有先有后，可以看Rebecca J. Wirfs-Brock写的1989年写的Object-Oriented Design：A Responsibility-Driven Approach，开头就指出了先考虑结构会破坏封装，才提出了RDD。

结构化方法是一个专有名词，所以我才用面向结构的方法的说法来避开它。至于RDD仅仅只是一种早期的思考，现在的发展已经很远了。

31 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

客观的说，我并不是一个业务平台的怀疑论者——我是一个业务平台的否定论者。

</p>
<p>       嗯，要听的就是这样一个干净利落的观点。</p>
<p>       你的观点就是，我们讨论一个根本就不存在东西的会出现的问题，所以该问题是个伪问题，就好比讨论公鸡下了蛋要是掉在水泥地上破了怎么办？</p>
<p>      其余的话：</p>
<p>      在业务流程图中元素也是专有名词，那些文件，数据库，处理，判断之类的，我所谓节点是其中的处理。</p>

30 楼 sslaowan 2007-12-20  

<p>

timerri 写道

引用

并非如你理解的，你所谓的抽象平台可能是IBM WDI，WPS那个系列提供的平台，跟我说的不是一回事，我说的平台比它高级。 而你理解的ozz所说的平台，也还不够准确，因为你所说的倾向于ERP平台。比如用友U8中，你可以根据你的实际业务，选定模块，然后组合你的需求，而我所说的平台比它底层。新业务的实现，是基于此种平台模块的二次开发过程。我不太理解你的这个说法是不是说，这个平台是用搭积木的方式组织的，但是这也是其文档就否定的做法。 或许我对于那个平台的宣传ppt和白皮书有误。

我有点不大明白你高级和底层的含义。高级是说功能更强大还是更抽象呢？底层是不是说允许比模块更低级的编程方式呢？ 如果把java甚至windows也看作一种业务平台，那么他们是更高级还是更低级呢？ 那个平台有没有名字？我也想切实的了解一下，或许我们会更容易勾通。

</p>
<p>      你按照我提的关键词去搜索吧，就能搜到那家公司，只是我觉得在这里提名字不好，一是给他做了宣传；二是在没用过的情况下指名道姓说人家东西行或不行都不好。所以我在文中只是引用其概念，提出疑问而已，我不持否定态度。</p>

29 楼 sslaowan 2007-12-20  

<p>

ronghao 写道

我是一个业务平台的支持者。我想说的是业务平台是有它存在的价值的。而它的价值恰恰体现在其对业务的理解上面，脱离开这个最基本的概念，我觉得都是扯淡。所以我一直对哪些所谓适用一切的平台很不以为然。而这种对业务的理解实际上能够极大的简化项目的开发。拿最简单的OA说事，OA里面最核心的业务就是发文和收文，这里面涉及到很多业务，比如说会签，比如说传阅、收回等等。你用JBPM来描述这些业务试试看，工作量大的去了。然而你用一些业务平台就能很轻松的解决这些问题。也就是业务平台要解决的其实是业务问题，而不是技术问题。至于说什么联动框、UI设计等等，你觉得是最重要吗？至于O6Z所说的元子组合的开发方式，还比较遥远不是。

</p>
<p>     你觉得用户体验不重要吗？或者用户要求提高一个在一个界面就能做所有事情的界面，那个界面大而复杂，不符合美学，但是那是用户需求，你觉得用户需求不重要吗？</p>
<p>      所以本文不拿OA说事，我已经说过很多次了</p>

28 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

引用

这个自顶向下，逐步细化的过程不就是经典的结构化方法吗？而结构化方法不是和面向过程方法是画等号的吗？见Ed Yourdon写的那个《Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design 》

还不能完全这么说。其实面向对象也是结构化方法的一支，而面向结构的方法则还具有其他的因素。比如既然你面向结构，那么就说明你先要对结构进行定义。而如果你从来不考虑结构，情况就会又有不同。同时既然你面向结构，那么结构的出现就会使最早被考虑的。但是如果你推迟考虑，情况又有所不同。同时就功能和结构的关系也很微妙，如果你将结构和功能完全的隔离开，就如同现代主义建筑里面很多的做法一样，情况又有不同。当然这里你可以就认为，面向结构的方法，就是在说面向过程和面向对象的。这样更加容易理解一些。

</p>
<p>     结构化方法是个专有名词啊，没有什么“其实”之类的说法了吧。当然无论什么方法都会出现结构和行为两个方面，而结构化方法和OO就是对其考虑有先有后，可以看<font>Rebecca J. Wirfs-Brock写的1989年写的<span lang='EN-US' style=''>Object-Oriented Design</span><span style=''>：</span><span lang='EN-US' style=''>A Responsibility-Driven Approach，开头就指出了先考虑结构会破坏封装，才提出了RDD。</span></font>  </p>
<p class='MsoNormal' align='left' style='line-height: 150%; text-align: left;'><strong><span lang='EN-US' style='font-size: 36pt; color: #00005f; line-height: 150%; font-family: Aachen-Bold;'>&lt;o:p&gt;&lt;/o:p&gt;</span></strong></p>

27 楼 yimlin 2007-12-20  

ozzzzzz 写道

面向结构的方法，是现在软件开发思想的一个主流方法。面向对象和面向过程，都可以被认为是面向结构方法的一个体现。其核心思想是，任何问题都可以被分析并分解为部分，可以被认为是由顶向下的方法。而组合的方法则刚好相反，其作用在于使用极少数基本元件，进行组合，从而形成复杂的体系，可以被认为是由下向顶发展的。分解的方法好处在于，可以在开始就确定一个很明确的目标，并且一直由其指引从而达成最后的结果。而组合的好处在于，开始的目标可以是模糊的，并且在组合的过程中，其效果也是发散的，其启动到完结都被外部的某些系统所约束和指引。

Ok, 现在已经明白"面向结构"其实指结构化的方法，无论是面向数据，面向过程还是面向对象都是一种结构化方法(至于后来的面向模式，面向服务都另说了)。但就结构化而言，本身也是有自上而下，还是自下而上的差异。所以个人以为组合本身也是结构化的一种，至于这种算是面向xxx则是再说的。
这个话题好像脱离本讨论主题，不在继续下去了

刚才google了一下，发现有“结构化系统分析方法”是自上而下的，看来和我自己所理解的“结构化方法”——“对系统进行从混沌到结构化”还是存在差异的，特此补充！