说说业务平台这件事
今天看了国内号称最大的业务平台产品的白皮书，也有朋友见过他们公司的产品演示，反应是巨牛无比！以前写过一篇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这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。
评论
在发展过程中,在嵌入不同 行业的解决方案
这种东西,首先,非设计者不能很好发挥
其次,完成简单的事情很简单,完成复杂的事情(这里所说的复杂的事情并不一定指业务真的复杂,软件这东西,变化太多),很不直观,你要花大量精力去探求解决方案
第三,最后还是要用它里面的编程语言去做一些事情,包括用sql做脏活
第四 要精通它,你要在上面花大量的投资,不光是钱,要花费大量的精力.这个精力,你投资在其它任何一种语言上都能做到高手级
其实,自己构建自己的业务平台并不复杂,特别是现在的.net /java环境和脚本语言,给你无穷的可能行. 总而言之,无非是
建立一套基础库(包括ui/orm等)
定义元数据,从元数据生成表,对象和ui
创建一个窗体设计器(现在的layout或是html布局都很简单0
创建一个插件结构
通过adapter模式生成不同应用的程序,比方说windows/web
此类等等,然后在这个上面在整入自己的业务应用.灵活性更大,可控性更高. 更重要的是,编程将更有趣味性
在软件行业,一个框架之类的东西要包办一切,那肯定是不行的
JJX这话还是蛮有意思的，设计的思路非常清晰。其实快速开发平台和业务基础平台还是有蛮大差异的；我们讨论时需要分得清楚些。我对业务基础平台还不是很熟悉，但对于快速开发平台，因为一直在做，还算了解。JJX指出一个基本的快速开发平台框架，但其实一个框架本身并不是最重要的，最重要的是你对粒度的把握，和你提供怎样的复用机制；这要些耐心和沉淀。
其实快速开发平台能够开发的软件类型还是非常多的，应对的复杂性也可以足够复杂，我们可以举出很多复杂或难以自动化实现的例子(楼主已经提出很多)，但有一点，不能通过这种方式来怀疑平台的价值，再复杂的东西也总是可以抽象后实现复用的，只要愿意投入平台可以做得足够强大。
建议怀疑者和否定者可以尝试下市场上的现有产品，特别是看看平台构造出的产品，有兴趣也可以看看我们在做的东西www.extract.com.cn；其实深入了解后我想可能会有想法上的变化。
平台是发展的方向，可能还没有到时候，否则也不会有这么多公司不断的投入；可以怀疑，但不能在听到或看到后仅凭3分钟的思考就认定其是夸大其词或在忽悠人。我们在这个方向上投入了8年时间，至今仍然认为这是个方向。
比如我们在分销系统时，所基于一种价格、库存模型，如果算法本身发了变化，有的时候，设计不慎，就会造成很大的影响，如果要过早的考虑未来的变化，妄图要封装未来、不可预测的逻辑变化，就变成过度设计，库表结构、程序结构都会复杂的很。
分层，Plug-in, component, framework, platform都只是一种分离粒度不同的技术手段，一种解决问题复杂度、降维的方式，而没有对业务的深刻理解，都是虚假的，而对业务最理解的，当然是你自己了，因为只有你奋站在用户的第一线上了，而不是那些厂商、Constant，他们只想拿到钱就走了，并且不要单心需求变化，因为他们所谓的平台，是和需求、业务没有关系的，而且他们吹嘘的就在此，那就是通用，只需要配置就可以完成一切，其实这是他们降低自己运营成本是一种方式，而不是真正的来解决你的问题。
严重同意，最讨厌空扯的人
[quote="jjx"]另外,lz说的应该是起步的x3吧,这里有个blog,可以看出其一些处理细节 可以看到它是如何应付一些业务复杂性 http://www.agilelabs.cn/blogs/ht/archive/tags/X3/default.aspx[/quote]
非常感谢，这份资料对我来说很有用~~等研究了之后，我们再讨论，我想我会有新的想法~
[quote="Godlikeme"]lz有没有看NetWeaver 的介绍，人家的定位是什么，“作为一个综合的集成和应用平台”。这个意思还不明确么？你们老师说人家是很技术的，是啊，人家自己也是这么说的，有什么问题么？ [/quote]
嗯，没问题，只是想说它不是技术无关的平台~~
http://www.agilelabs.cn/blogs/ht/archive/tags/X3/default.aspx
早期就是mbf (Microsoft Business framework) 后来叫project green,用于ms erp 的基础框架 .mbf的内部版本我琢磨过很长时间.不过后来ms放弃了
http://download.microsoft.com/download/E/E/6/EE6154A8-6082-43CB-83E9-8389DDCA141A/DAT340.ppt
devexpress 现在出了个xaf ,也是走类似的路线,不过都绑定到express的产品线上. 我们能做的就是此类类似的东西
http://www.devexpress.com/Products/NET/Libraries/eXpressApp/
现在,像ms的dynamics ax ,就是一个平台,里面有个ato,就是用于开发. 有个类似java的脚本语言.内容包括数据字典,ui设计,报表,数据源,action等等. 说实际点,就是一个编程环境,修改的东西分层保存(不过这里面居然没有工作流,当然现在整个工作流也不是个难事了)
其实，我认为目前国内的金蝶、用友做出来的东东，应该就是这个。
就目前而言，如果能够做到这个程度，估计也就算得上是国内一流的企业了。
我的理解如下：
行业业务平台=技术平台+业务组件
当然，这只是个被简化了的公式。不过，我觉得做到这个程度就应该能解决大部分问题了。
通用的东西，能够解决80%的常见问题就不错了。另外的20%，还是让项目组来解决吧。
在发展过程中,在嵌入不同 行业的解决方案
这种东西,首先,非设计者不能很好发挥
其次,完成简单的事情很简单,完成复杂的事情(这里所说的复杂的事情并不一定指业务真的复杂,软件这东西,变化太多),很不直观,你要花大量精力去探求解决方案
第三,最后还是要用它里面的编程语言去做一些事情,包括用sql做脏活
第四 要精通它,你要在上面花大量的投资,不光是钱,要花费大量的精力.这个精力,你投资在其它任何一种语言上都能做到高手级
其实,自己构建自己的业务平台并不复杂,特别是现在的.net /java环境和脚本语言,给你无穷的可能行. 总而言之,无非是
建立一套基础库(包括ui/orm等)
定义元数据,从元数据生成表,对象和ui
创建一个窗体设计器(现在的layout或是html布局都很简单0
创建一个插件结构
通过adapter模式生成不同应用的程序,比方说windows/web
此类等等,然后在这个上面在整入自己的业务应用.灵活性更大,可控性更高. 更重要的是,编程将更有趣味性
在软件行业,一个框架之类的东西要包办一切,那肯定是不行的
[quote="dyuan"]看到大家回复了这么多，还不如花点时间，了解一下Justep的平台，普元的EOS平台，浪潮的楼上平台，各有各的灵活和优点。然后再来讨论对平台的理解，我觉得这样比较实在[/quote]
本文就是基于您说的平台中的一个讨论的，不过我只是看了他的技术白皮书，和听别人跟我讲的他的演示过程，从他的白皮书之类的东西，我看到了他说他是一个技术无关的平台，并且主要的论述都是在说他们的平台改变了过去人们从技术开始构建mis的方式，而采用从业务出发，不需要考虑技术。由于我没真正使用过，所以才发出这些疑问。
发此帖是更加希望有用过的同志能说一下，这个平台到底是怎么回事。既然您这么说，估计您是用过以上三种平台了，那么就请你您说说看~~
我前几天问我们老师SAP 的Netweaver，老师说那个平台也还相当技术，说什么技术无关的平台，估计还得努力几百年~
我不是这类平台的否定者（跟经验丰富的o6z不同），我只是怀疑者，对于其宣称技术无关的怀疑者，对于其对于过去开发mis 的方式的否定的怀疑者
[quote="fight_bird"]世界本没有什么救世主！ 各位有人研究过“XYZ系统”吗？那玩意理论上可以实现所有的商业逻辑，但谁见到一个商用的产品？ 业务平台降格为业务组件库+业务基础设施更恰当。[/quote]
嗯，这个比较同意
[quote="Godlikeme"]看了lz重申部分。对于这个问题，答案相对比较明确，这种"平台"是一种技术层面的封装。根本就不是什么平台，就是一种抽象层次更高的技术，基于某些技术抽象的快速开发框架及其快速开发规范。没有从任何方面降低业务问题的复杂度和技术问题的复杂度。除了商业炒作似乎没有太大实际意义。[/quote]
商业的复杂性是固有复杂性，是不可能通过技术降低的，如果能实现快速开发就很不错了。
各位有人研究过“XYZ系统”吗？那玩意理论上可以实现所有的商业逻辑，但谁见到一个商用的产品？
业务平台降格为业务组件库+业务基础设施更恰当。
对于这个问题，答案相对比较明确，这种"平台"是一种技术层面的封装。根本就不是什么平台，就是一种抽象层次更高的技术，基于某些技术抽象的快速开发框架及其快速开发规范。没有从任何方面降低业务问题的复杂度和技术问题的复杂度。除了商业炒作似乎没有太大实际意义。
[quote="sofar1218"]业务平台是相对的,UI也是业务平台 (或者叫领域,问题域),本质就是描述与实现分离,所以问题域也有自己的语言, 比如 svg html css[/quote]
其实这正是我对于有人说业务平台就是中间层做的事情有点怀疑，你说页面流程难道和业务没关系，先填什么后填什么，难道不是业务？
[quote="Godlikeme"]拜托，不好把问题分解和结构化方法、OO方法搞混淆吧，不是一个范畴。[/quote]
很明显，我没说问题分解和两大编程范型是同一 级别的，好比原型法 和两大过程范型（顺序和迭代）不是同一级别
发表评论
提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则
- 浏览: 29614 次
- 性别:
- 来自: 北京
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
说说业务平台这件事
jjx 写道所谓的这些技术平台,其实就是一个整合环境(比较典型的就是把建表,生成 ...
-- by sunwine -
J2EE安全问题
你多看一寫acegi的資料，就會明白很多
-- by guojingxf -
一条凭空消失的短信引发的 ...
lordhong 写道农村扫盲?? 哪个村儿的？
-- by weiqingfei -
一条凭空消失的短信引发的 ...
lordhong 写道农村扫盲??写调研报告写烦了，模仿《探索发现》的风格写的， ...
-- by sslaowan -
一条凭空消失的短信引发的 ...
农村扫盲??
-- by lordhong
评论排行榜