说说业务平台这件事

       今天看了国内号称最大的业务平台产品的白皮书，也有朋友见过他们公司的产品演示，反应是巨牛无比！以前写过一篇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这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。

评论

26 楼 ronghao 2007-12-20  

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

25 楼 hyhongyong 2007-12-20  

宣传，一切都是宣传！
非常同意o6z的论点！
现在流行“忽悠”，软件业特别严重啊！

24 楼 LucasLee 2007-12-20  

gfh21cn 写道

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

这个有点意思,平台本身就是为了提高代码重用和开发效率的,至于是否需要编码这个都不重要.一般来说,平台的灵活性是最被轻视的部分.一般平台演示的都是搭建一个常见的功能界面是多么多么快速和简单,但缺乏的就是对复杂和大型软件的支持.如何对很复杂的情况下进行编程?(肯定要允许自定义编程),而且要尽量减少对编程的影响.比如只允许用脚本编码就是一个比较糟糕的选择,限制了软件适合的复杂性规模. 要对OO化的,模块化的编程有支持和引导.在程序员能利用平台提高开发效率的同时,不要让复杂的需要客户化编程的那部分比不用平台更复杂--或者不要复杂太多. 这样的话,总的来说,平台才是好用的,有价值的.

23 楼 gfh21cn 2007-12-20  

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

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

 

22 楼 timerri 2007-12-20  

引用

   并非如你理解的，你所谓的抽象平台可能是IBM WDI，WPS那个系列提供的平台，跟我说的不是一回事，我说的平台比它高级。

  而你理解的ozz所说的平台，也还不够准确，因为你所说的倾向于ERP平台。比如用友U8中，你可以根据你的实际业务，选定模块，然后组合你的需求，而我所说的平台比它底层。新业务的实现，是基于此种平台模块的二次开发过程。我不太理解你的这个说法是不是说，这个平台是用搭积木的方式组织的，但是这也是其文档就否定的做法。

  或许我对于那个平台的宣传ppt和白皮书有误。

我有点不大明白你高级和底层的含义。高级是说功能更强大还是更抽象呢？
底层是不是说允许比模块更低级的编程方式呢？


如果把java甚至windows也看作一种业务平台，那么他们是更高级还是更低级呢？


那个平台有没有名字？我也想切实的了解一下，或许我们会更容易勾通。

21 楼 ozzzzzz 2007-12-20  

引用

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

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

20 楼 ozzzzzz 2007-12-20  

引用

我觉得这个问题是个基础问题，迭代方法，OO范型的出现，就是因为客户需求会“得寸进尺”，客户永远是这样的，在需求阶段时，只是满足其现有业务的计算机化即可，但是一旦满足这一要求后，就开始提出UI友好性，系统智能性，辅助管理与决策，等等一系列新要求，那时候我在客户现场，基本上就是3天一个小迭代周期，如果你的体系结构不易扩展，那就必死，客户往往说，不就是加个XXX吗？怎么如此费劲？

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

引用

你所谓业务原子，是否可以理解为业务流程图（结构化方法中的那个概念）上的某个节点？这一点，我们在面向对象，基于组件，面向服务出现时，就在考虑如何进行更合理的分析与设计了，这个也是业务平台思想的动机之一。

应该是业务元子，而非业务原子。原子再小，也可以继续细分。而元子再大，其依然不能细分。业务元子的概念，可以理解为，具有业务最小意义的业务行为，其活动是基础性的，可以是无动机或者多动机的，同时又是被组合的，不会单独出现的。
显然业务元子不是你说的业务流程图的某个节点，而是业务流程图的构成元素。
这里其实还存在一个问题我没说，那就是组合和分解的思路如此不同，以至于在切换的时候，反映会十分巨大。那么究竟什么时候是切换的时机呢？

引用

如果有如此强大的平台出现，意味着软件行业的分工将进一步细化，平台开发者，业务开发者（有的人叫配置者，很方正之类的公司也有这种东西）。

恰恰是如果此种平台出现，软件行业的分工将变得没有必要。第一，平台将是快速自我发展的，而只有开发者才能理解。第二，业务将被强力绑定在此业务平台上，而一旦进入元子方法主导的阶段，所有的工作都仅仅是基于元子的组合，因此也不需要进一步分工。第三，由于业务和平台都具有极其快速的变化，只可能有少数的个别人才能够将两者联系起来，同时又由于存在的速度如此快，其向别人转达的成本和可能将变得不可被接受。

引用

其实认真看下来，最不理解的就是这句了，如何理解伪问题这个概念呢？
       只是觉得，你是一个彻底的对于这种平台的怀疑者，其实本文对于这种平台的定义是非常清晰的，一个号称与技术无关的抽象业务平台，可以快速解决企业信息系统核心问题。

大概我这个年纪的人，都对以前的事情记忆太多。CASE和方法论大战，都让我对这些宣传具有无比能力的工具保持戒心。除非有一个最低智商超过190的团体存在，否则如此强大的平台根本就不存在理论的基础。所以其实际是否存在，根本就不需要讨论。而一旦业务被抽象的过程启动，其最终的结局就只能是一种技术，并且仅仅只是一种技术。
当然我相信平台的存在是有意义的，只不过我不相信存在一种这么具有业务相关性，而无技术相关性的平台存在，同时我还不相信具有如此大的能量，更不相信还具有如此广泛的适应范围，更加不相信其能生存这么久。
客观的说，我并不是一个业务平台的怀疑论者——我是一个业务平台的否定论者。

19 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

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

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

18 楼 sslaowan 2007-12-20  

<p>

timerri 写道

（所谓伪问题，就是说这个问题没有意义.......） ozz所说的平台，应该是一种实现平台，也就是说基于这个平台的业务是由平台提供的固定的功能模块组合而成。新业务的实现，是基于此种平台模块的二次开发过程.. 而lz所说的平台，应该是一种抽象平台，只制定业务处理规则，而不管其实现。这样的平台更强调一种方法论。新业务的实现，是基于扩充或者替换平台自身来实现.. 大家说得其实都对，对象不同而以..... 我还是对抽象平台比较看好的，只不过我认为这个东西的工业价值是远远大于商业价值的。抽象平台的优点就是规范了技术的实现，规范了分工，但其技术上的实现却没能有任何简化。如果抽象平台过多的涉及了实现，那么实现平台出现的问题，也会出现在这种抽象平台上。呵呵，这就是ozz所说的抽象与实现的矛盾。

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

17 楼 ozzzzzz 2007-12-20  

yimlin 写道

ozzzzzz 写道

我最近在思考一个问题，算作对这个讨论的注解。你的希望你开发的软件在使用的过程中是否能做到尽量有效，这一点我想不是问题。但是一旦你的软件是有效的，那么对客户的业务流程就会造成深刻的影响，其成本和效率的分配就会随之发生变化，从而进一步促成客户对其业务进一步的进行优化和重组，进而再次造成你的系统不能满足需要，于是进入一个循环。这是一个背景问题，需要我们时刻考虑。
而业务平台的建设，其实是建立在一个最简单的假设的基础上的——业务可以很明确使用一个方法进行形式化的建模，并且这个方法可以在建模的过程中自我完善。而当建模方法自我完善的速度，低于业务自我完善的速度，那么这个方法就将失效，从而其基础上的平台也将失效。
另外一个问题，一个业务平台如果涉及的领域很宽泛而模糊，那么其建模的方法将更加具有抽象性。而一旦抽象性达到与具体逻辑的抽象过于遥远，使用其构建具象化抽象所要付出的代价将大幅度提升，从而造成其使用价值降低。而一旦当其抽象为一种数学函数，实际上其本身就形成了一种新的编程语言，这个时候起复杂性和易用性将回到平台构建的初始阶段，从而需要再一次构建新的平台。也就是说，如果过于追求应用的普遍性，那么就将成为一个构建平台的快速循环，从而造成其过早失效。
而当业务处于快速演变期，对业务的抽象和分解也将开始快速演变。当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。
而如果把软件开发看作一种商业行为，也就是开放者需要考虑维护自己的利益，那么其就不存在构建一个如此强大平台的动机。当然今天的社会，宣传和实际的差距可以被认为趋于无限的不相关。所以这样的平台，是否存在或者可能存在，就只能是一个伪问题。

说的太好了！
我也看过EOS，我一直担心的是这些所谓的通用平台本身没有提供业务建模的解决能力，而其引入的新机制可能让简单的事更简单，但由于和传统语言的隔离和差异，导致复杂的更复杂。

BTW：“当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。”
隐隐可以理解你的意思，但是能否解释一下“面向结构”是啥含义，期望大家对此理解一致。

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

16 楼 timerri 2007-12-20  

（所谓伪问题，就是说这个问题没有意义.......）

ozz所说的平台，应该是一种实现平台，也就是说基于这个平台的业务是由平台提供的固定的功能模块组合而成。新业务的实现，是基于此种平台模块的二次开发过程..

而lz所说的平台，应该是一种抽象平台，只制定业务处理规则，而不管其实现（虽然它可能有了某种实现）。这样的平台更强调一种方法论。新业务的实现，是基于扩充或者替换平台自身来实现..

大家说得其实都对，对象不同而以.....

我还是对抽象平台比较看好的，只不过我认为这个东西的工业价值是远远大于商业价值的。抽象平台的优点就是规范了技术的实现，规范了分工，但其技术上的实现却没能有任何简化。如果抽象平台过多的涉及了实现，那么实现平台出现的问题，也会出现在这种抽象平台上。呵呵，这就是ozz所说的抽象与实现的矛盾。

15 楼 sslaowan 2007-12-20  

<p>

ozzzzzz 写道

但是一旦你的软件是有效的，那么对客户的业务流程就会造成深刻的影响，其成本和效率的分配就会随之发生变化，从而进一步促成客户对其业务进一步的进行优化和重组，进而再次造成你的系统不能满足需要，于是进入一个循环。这是一个背景问题，需要我们时刻考虑。

</p>
<p>         我觉得这个问题是个基础问题，迭代方法，OO范型的出现，就是因为客户需求会“得寸进尺”，客户永远是这样的，在需求阶段时，只是满足其现有业务的计算机化即可，但是一旦满足这一要求后，就开始提出UI友好性，系统智能性，辅助管理与决策，等等一系列新要求，那时候我在客户现场，基本上就是3天一个小迭代周期，如果你的体系结构不易扩展，那就必死，客户往往说，不就是加个XXX吗？怎么如此费劲？</p>
<p>         </p>
<p>

ozzzzzz 写道

而当建模方法自我完善的速度，低于业务自我完善的速度，那么这个方法就将失效，从而其基础上的平台也将失效。

</p>
<p>        这正是我的怀疑点，本文所讨论的领域背景，一定是大型、复杂、企业级信息系统，具体而言是核心业务系统，而非OA一类的。</p>
<p>

ozzzzzz 写道

另外一个问题，一个业务平台如果涉及的领域很宽泛而模糊，那么其建模的方法将更加具有抽象性。而一旦抽象性达到与具体逻辑的抽象过于遥远，使用其构建具象化抽象所要付出的代价将大幅度提升，从而造成其使用价值降低。

</p>
<p>           UML2.0之所以无法实现更大的价值，或者xUML的思想难以实现，就是因为其过于复杂了，对于开发者而言为何要使用复杂图形代替简单的编程，其动机是不充分的。</p>
<p>

ozzzzzz 写道

而一旦当其抽象为一种数学函数，实际上其本身就形成了一种新的编程语言，这个时候起复杂性和易用性将回到平台构建的初始阶段，从而需要再一次构建新的平台。也就是说，如果过于追求应用的普遍性，那么就将成为一个构建平台的快速循环，从而造成其过早失效。

</p>
<p>           所以我在回复中说，如果为了区分不同函数，引入命名空间，引入对象等，那与引入新的编程语言有何差异？</p>
<p>           

ozzzzzz 写道

而当业务处于快速演变期，对业务的抽象和分解也将开始快速演变。当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。

</p>
<p>           你所谓业务原子，是否可以理解为业务流程图（结构化方法中的那个概念）上的某个节点？这一点，我们在面向对象，基于组件，面向服务出现时，就在考虑如何进行更合理的分析与设计了，这个也是业务平台思想的动机之一。</p>
<p> 

ozzzzzz 写道

而如果把软件开发看作一种商业行为，也就是开放者需要考虑维护自己的利益，那么其就不存在构建一个如此强大平台的动机。

</p>
<p>           如果有如此强大的平台出现，意味着软件行业的分工将进一步细化，平台开发者，业务开发者（有的人叫配置者，很方正之类的公司也有这种东西）。              </p>
<p> 

ozzzzzz 写道

当然今天的社会，宣传和实际的差距可以被认为趋于无限的不相关。所以这样的平台，是否存在或者可能存在，就只能是一个伪问题。

</p>
<p>              其实认真看下来，最不理解的就是这句了，如何理解伪问题这个概念呢？</p>
<p>             只是觉得，你是一个彻底的对于这种平台的怀疑者，其实本文对于这种平台的定义是非常清晰的，一个号称与技术无关的抽象业务平台，可以快速解决企业信息系统核心问题。</p>
<p>            </p>

14 楼 yimlin 2007-12-20  

ozzzzzz 写道

我最近在思考一个问题，算作对这个讨论的注解。你的希望你开发的软件在使用的过程中是否能做到尽量有效，这一点我想不是问题。但是一旦你的软件是有效的，那么对客户的业务流程就会造成深刻的影响，其成本和效率的分配就会随之发生变化，从而进一步促成客户对其业务进一步的进行优化和重组，进而再次造成你的系统不能满足需要，于是进入一个循环。这是一个背景问题，需要我们时刻考虑。
而业务平台的建设，其实是建立在一个最简单的假设的基础上的——业务可以很明确使用一个方法进行形式化的建模，并且这个方法可以在建模的过程中自我完善。而当建模方法自我完善的速度，低于业务自我完善的速度，那么这个方法就将失效，从而其基础上的平台也将失效。
另外一个问题，一个业务平台如果涉及的领域很宽泛而模糊，那么其建模的方法将更加具有抽象性。而一旦抽象性达到与具体逻辑的抽象过于遥远，使用其构建具象化抽象所要付出的代价将大幅度提升，从而造成其使用价值降低。而一旦当其抽象为一种数学函数，实际上其本身就形成了一种新的编程语言，这个时候起复杂性和易用性将回到平台构建的初始阶段，从而需要再一次构建新的平台。也就是说，如果过于追求应用的普遍性，那么就将成为一个构建平台的快速循环，从而造成其过早失效。
而当业务处于快速演变期，对业务的抽象和分解也将开始快速演变。当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。
而如果把软件开发看作一种商业行为，也就是开放者需要考虑维护自己的利益，那么其就不存在构建一个如此强大平台的动机。当然今天的社会，宣传和实际的差距可以被认为趋于无限的不相关。所以这样的平台，是否存在或者可能存在，就只能是一个伪问题。

说的太好了！
我也看过EOS，我一直担心的是这些所谓的通用平台本身没有提供业务建模的解决能力，而其引入的新机制可能让简单的事更简单，但由于和传统语言的隔离和差异，导致复杂的更复杂。

BTW：“当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。”
隐隐可以理解你的意思，但是能否解释一下“面向结构”是啥含义，期望大家对此理解一致。

13 楼 ozzzzzz 2007-12-20  

rihoonet 写道

“是否存在或者可能存在，就只能是一个伪问题”，我觉得并不是一个伪问题，因为它现在确实存在，且起着积极作用。业务并台，并不能解决全部的业务问题，但能解决一般的通用性问题（我们的软件，一般通用性的问题应该比较多），其它很复杂的问题，要靠升级或脚本等实现，就像现在的eclipse等一样，也要升级，要不断完善，业务平台也应如此。

请重读我上篇回答3遍。

12 楼 rihoonet 2007-12-20  

“是否存在或者可能存在，就只能是一个伪问题”，我觉得并不是一个伪问题，因为它现在确实存在，且起着积极作用。业务并台，并不能解决全部的业务问题，但能解决一般的通用性问题（我们的软件，一般通用性的问题应该比较多），其它很复杂的问题，要靠升级或脚本等实现，就像现在的eclipse等一样，也要升级，要不断完善，业务平台也应如此。

11 楼 ozzzzzz 2007-12-20  

我最近在思考一个问题，算作对这个讨论的注解。你的希望你开发的软件在使用的过程中是否能做到尽量有效，这一点我想不是问题。但是一旦你的软件是有效的，那么对客户的业务流程就会造成深刻的影响，其成本和效率的分配就会随之发生变化，从而进一步促成客户对其业务进一步的进行优化和重组，进而再次造成你的系统不能满足需要，于是进入一个循环。这是一个背景问题，需要我们时刻考虑。
而业务平台的建设，其实是建立在一个最简单的假设的基础上的——业务可以很明确使用一个方法进行形式化的建模，并且这个方法可以在建模的过程中自我完善。而当建模方法自我完善的速度，低于业务自我完善的速度，那么这个方法就将失效，从而其基础上的平台也将失效。
另外一个问题，一个业务平台如果涉及的领域很宽泛而模糊，那么其建模的方法将更加具有抽象性。而一旦抽象性达到与具体逻辑的抽象过于遥远，使用其构建具象化抽象所要付出的代价将大幅度提升，从而造成其使用价值降低。而一旦当其抽象为一种数学函数，实际上其本身就形成了一种新的编程语言，这个时候起复杂性和易用性将回到平台构建的初始阶段，从而需要再一次构建新的平台。也就是说，如果过于追求应用的普遍性，那么就将成为一个构建平台的快速循环，从而造成其过早失效。
而当业务处于快速演变期，对业务的抽象和分解也将开始快速演变。当然业务最终可以被分解为一系列的业务元子，也就是说业务将是这些元子的组合；这时建模的重点将主要以更强大的组合能力为首要要求，而显然基于现有的面向结构的软件开发思维方法讲变得越来越低效率，从而造成以其为基础思维方式所构成的业务平台失效。
而如果把软件开发看作一种商业行为，也就是开放者需要考虑维护自己的利益，那么其就不存在构建一个如此强大平台的动机。当然今天的社会，宣传和实际的差距可以被认为趋于无限的不相关。所以这样的平台，是否存在或者可能存在，就只能是一个伪问题。

10 楼 sslaowan 2007-12-20  

<p>

rihoonet 写道

sslaowan 写道

这些我懂，不过我考虑的现实

实现，都是靠平时项目的积累来的，多多看看别人的项目或业务平台是怎么解决你提的那几点问题的，然后将优秀的解决方案，结合到自己的平台中。你说到的维护比较难，那你说说你维护一段通用的代码比较好，还是维护多个项目的代码比较好呢？

</p>
<p> </p>
<p>                      我就是因为看不到那个牛平台的源代码，也不知道它的实现机理，也没见过它的应用，才会提出自己的担心，如果我见过，我用过，我就直接可以说出，嗯，牛的很，不会出任何问题；或者，还是会出问题了。</p>
<p> </p>
<p>                       我觉得恰恰使用那种平台才会造成复用性受损，因为你在那个小小的节点上实现的方法，可能会被很多程序使用，当然，平台也会支持你把它抽成系统级别的函数，甚至可以像使用Java一样，定义包结构，管理类，声明其private，public之类的，那我不知道这种使用和使用Java IDE之间，哪个更舒服，更优雅。</p>
<p>                         你说的那个维护通用代码之类的，那是最基本的编程原则了，不在我讨论的范围之内</p>

9 楼 sslaowan 2007-12-20  

<p>

rihoonet 写道

其实平台，就是抽象出很多业务特性而形成的（当然少不了积累）。当然，填报表单、增、删、改也是业务特性的一部分，都是业务平台要考虑的。然而，平台不能解决所有的业务需求，所以它会通过脚本（JavaScript等），来扩展与完善它不能实现的功能。

</p>
<p>   你还是没理解我说的，我文中已经提到了，可以通过某种其支持的语言进行扩展，比如那个OA用的是VB，文中提的那个牛平台用的是Delphi，这些我知道，对于它实现的原理我也理解，但是当你发现你还需要编码解决你过去就要解决的复杂问题（这些平台原本告诉我不需要），而且使用一种非常不好的方式，我在修改旧系统代码时，看到一千多行的函数，充满了条件分支和魔法数字，大段大段的重复代码，是多么的恶心。</p>
<p>    所以我说，这类平台是不是只是将简单的问题简单化了，对于复杂的问题依然提供复杂甚至是更加复杂的解决方案</p>

8 楼 sslaowan 2007-12-20  

<p>

OneEyeWolf 写道

关键是我们要对“业务平台”这个词语没有一个定义，这是个伪明题。 像你在文章中反复说的下拉框、UI，这些是业务吗，是与业务无关的东西剥离出来的一种框架解决方案而已，更不能说是平台中的特色吧。 就是工作流引擎，也是为了将流程定制、跳转与业务逻辑剥离出来的一种设计思想的实施。 表单定制更不是业务，也是与业务剥离的一种方式。 而在现实开发当中，做为一个有成熟技术积累的行业软件公司，这些都是个屁，根本不值得一提，早就有了，技术含量也高不到那去。在Delphi时代，他们就有了各种VCL组件、框架，功能比这强大多了，他们真正关心、头疼的不是这个。 

</p>
<p> </p>
<p>         我在这里讲的业务平台，不是J2EE这种底层的开发平台，不是ERP这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。</p>
<p>       我参与过两个用Delphi开发的大项目，一个Form上有超多控件，页面流程超级复杂，各控件之间的关系也非常复杂，这其实也很头疼。</p>
<p>      你所说的表现层的问题我当然知道，只不过这类平台号称“技术无关”实在值得怀疑，企业信息系统每个环节都很费劲。</p>
<p>     用友，金蝶，易飞，易助的ERP系统我全都用过，因为我们学校是他们的合作伙伴。我的感觉是其实现的功能都很固定，与我本文中提到的平台不是一个概念。</p>
<p>     从我的发言可以看出，我所怀疑的，正是这些平台是如何解决我在过去的开发中遇到的核心复杂难题，比如UI设计，业务逻辑实现，持久化设计等等</p>

7 楼 rihoonet 2007-12-19  

不知道楼上的为什么有这样的理解