2008-7-18 13:43
hawk_e2e
现在有些宣称平台的公司。其实就是：
1.把常用的功能封装起来，向外提供接口。
2.把一些主要的组件（如：工作流）整合起来，并提供一定的扩展能力。
用这些平台来开发系统，业务里适用的那部分，开发是容易的，但不适用的那部分，跟重新开发无异。
平台稳定好用还好办，不稳定又难用那就比直接用开发工具还糟糕。
所以平台还是不要太强大为好。
1.把常用的功能封装起来，向外提供接口。
2.把一些主要的组件（如：工作流）整合起来，并提供一定的扩展能力。
用这些平台来开发系统，业务里适用的那部分，开发是容易的，但不适用的那部分，跟重新开发无异。
平台稳定好用还好办，不稳定又难用那就比直接用开发工具还糟糕。
所以平台还是不要太强大为好。
2008-7-18 13:54
luoxiang_sh
[quote]原帖由 [i]szeng19[/i] 于 2008-7-18 09:59 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10987967&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
不幸被你言中，你所希望看到的平台，抛弃java，c#,DELH之类的程序语言，让业务专家真正能够不懂开发语言就能调整业务，通过配置就能实现逻辑。并且是透明可视化的操作，马上就要面市了。我们现在正在做beta测试，有4个体验客户，也许奥运会后你就可以看到，呵呵 [/quote]
我是顶点负责销售LiveBOS的，看来大家对LiveBOS平台不甚了解，实际上LiveBOS开发历时5年了，约在2年前产品正式推向市场，现在金融证券业、制造业、政府部门，电力，电信等多个行业已经有了大量的应用案例。而在证券行业，顶点现有的数十名基于平台开发应用管理软件工程师，目前没有一个人写java代码，开发的成功上线大型软件，已经有几十家的客户，销售收入2多千万。至于所谓真正业务架构平台更本不存在的说法，未免过于武断了吧。有兴趣的人，不妨和我联系，或访问[url=http://www.livebos.com]http://www.livebos.com[/url]。
不幸被你言中，你所希望看到的平台，抛弃java，c#,DELH之类的程序语言，让业务专家真正能够不懂开发语言就能调整业务，通过配置就能实现逻辑。并且是透明可视化的操作，马上就要面市了。我们现在正在做beta测试，有4个体验客户，也许奥运会后你就可以看到，呵呵 [/quote]
我是顶点负责销售LiveBOS的，看来大家对LiveBOS平台不甚了解，实际上LiveBOS开发历时5年了，约在2年前产品正式推向市场，现在金融证券业、制造业、政府部门，电力，电信等多个行业已经有了大量的应用案例。而在证券行业，顶点现有的数十名基于平台开发应用管理软件工程师，目前没有一个人写java代码，开发的成功上线大型软件，已经有几十家的客户，销售收入2多千万。至于所谓真正业务架构平台更本不存在的说法，未免过于武断了吧。有兴趣的人，不妨和我联系，或访问[url=http://www.livebos.com]http://www.livebos.com[/url]。
2008-7-18 21:52
hpls
[quote]原帖由 [i]szeng19[/i] 于 2008-7-9 23:32 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10903902&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
我所持的观点是，如果平台软件不能让业务专家，也就是有有一点（注意，是一点而不是精通）技术能力并有丰富业务经验的客户使用，那这个平台就很失败。说白了，只不过开发了一个二次的IDE，封装了一些控件或者对象，方便进行二次开发而已。注意这里的用词，是二次开发，并不是简单配置。这样的平台对最终用户来说，意义不大，只是一个技术平台而已，客户要反问，我用这个技术平台对我来说有什么用？？客户价值何在？
[/quote]
szeng19 的这个观点我很赞同，但是现在平台市场 疑似这样的产品很多，而且都貌似如此定位，为了能让客户接受又冠以很多新的名词来混淆客户的注意力，当技术本质被营销手段虚化那就太可怕了，希望大家都能擦亮眼睛啊！
[quote]原帖由 [i]szeng19[/i] 于 2008-7-9 23:32 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10903902&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
另外来说，成熟的业务平台和技术平台的显著不同，就是技术平台专注技术本身，其体系可能比较复杂和完备，但缺乏现成的实例。而成熟业务平台是一个最佳案例的集合，在平台提供的同时，已经有一个最佳案例库供客户可以选择和使用。这方面做得比较好的比如SAP，国内也不乏有公司在做这方面的努力，不过就我个人来看，楼主体积的几个产品都不在此列，呵呵... [/quote]
这点我不是很赞同，平台的定位是业务需求的描述工具，业务软件的生成工具，这和成熟的应用软件有很大的区别，既然定位是平台就不要去和具有多行业解决方案的应用系统去对比案例，就像成熟应用系统不会和你比技术架构，这两者没有可比性。
而且既然是平台，那么随着客户的使用，你还怕没有案例，所有客户应用後生成的业务软件都是案例，只要平台提供很好的导入导出工具，实现业务模型和生成的应用系统之间的可逆，我想没有那个应用产品能比得上。就像很多软件开发者会围绕软件开发工具开发很多控件一样，平台的使用者也同样可以共享自己的业务模型供大家去交流使用。
ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！
[[i] 本帖最后由 hpls 于 2008-7-18 22:02 编辑 [/i]]
我所持的观点是，如果平台软件不能让业务专家，也就是有有一点（注意，是一点而不是精通）技术能力并有丰富业务经验的客户使用，那这个平台就很失败。说白了，只不过开发了一个二次的IDE，封装了一些控件或者对象，方便进行二次开发而已。注意这里的用词，是二次开发，并不是简单配置。这样的平台对最终用户来说，意义不大，只是一个技术平台而已，客户要反问，我用这个技术平台对我来说有什么用？？客户价值何在？
[/quote]
szeng19 的这个观点我很赞同，但是现在平台市场 疑似这样的产品很多，而且都貌似如此定位，为了能让客户接受又冠以很多新的名词来混淆客户的注意力，当技术本质被营销手段虚化那就太可怕了，希望大家都能擦亮眼睛啊！
[quote]原帖由 [i]szeng19[/i] 于 2008-7-9 23:32 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10903902&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
另外来说，成熟的业务平台和技术平台的显著不同，就是技术平台专注技术本身，其体系可能比较复杂和完备，但缺乏现成的实例。而成熟业务平台是一个最佳案例的集合，在平台提供的同时，已经有一个最佳案例库供客户可以选择和使用。这方面做得比较好的比如SAP，国内也不乏有公司在做这方面的努力，不过就我个人来看，楼主体积的几个产品都不在此列，呵呵... [/quote]
这点我不是很赞同，平台的定位是业务需求的描述工具，业务软件的生成工具，这和成熟的应用软件有很大的区别，既然定位是平台就不要去和具有多行业解决方案的应用系统去对比案例，就像成熟应用系统不会和你比技术架构，这两者没有可比性。
而且既然是平台，那么随着客户的使用，你还怕没有案例，所有客户应用後生成的业务软件都是案例，只要平台提供很好的导入导出工具，实现业务模型和生成的应用系统之间的可逆，我想没有那个应用产品能比得上。就像很多软件开发者会围绕软件开发工具开发很多控件一样，平台的使用者也同样可以共享自己的业务模型供大家去交流使用。
ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！
[[i] 本帖最后由 hpls 于 2008-7-18 22:02 编辑 [/i]]
2008-7-18 22:02
hpls
[quote]原帖由 [i]hawk_e2e[/i] 于 2008-7-18 13:43 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10991781&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
现在有些宣称平台的公司。其实就是：
1.把常用的功能封装起来，向外提供接口。
2.把一些主要的组件（如：工作流）整合起来，并提供一定的扩展能力。
用这些平台来开发系统，业务里适用的那部分，开发是容易的，但不适用的那部分，跟重新开发无异。
平台稳定好用还好办，不稳定又难用那就比直接用开发工具还糟糕。
所以平台还是不要太强大为好。 [/quote]
哈哈，总结的太好了，这样的产品一抓一大把啊！
现在有些宣称平台的公司。其实就是：
1.把常用的功能封装起来，向外提供接口。
2.把一些主要的组件（如：工作流）整合起来，并提供一定的扩展能力。
用这些平台来开发系统，业务里适用的那部分，开发是容易的，但不适用的那部分，跟重新开发无异。
平台稳定好用还好办，不稳定又难用那就比直接用开发工具还糟糕。
所以平台还是不要太强大为好。 [/quote]
哈哈，总结的太好了，这样的产品一抓一大把啊！
2008-7-18 22:04
hpls
[quote]原帖由 [i]szeng19[/i] 于 2008-7-18 09:59 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10987967&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
不幸被你言中，你所希望看到的平台，抛弃java，c#,DELH之类的程序语言，让业务专家真正能够不懂开发语言就能调整业务，通过配置就能实现逻辑。并且是透明可视化的操作，马上就要面市了。我们现在正在做beta测试，有4个体验客户，也许奥运会后你就可以看到，呵呵 [/quote]
:) 给个beta版说明看哈撒！
不幸被你言中，你所希望看到的平台，抛弃java，c#,DELH之类的程序语言，让业务专家真正能够不懂开发语言就能调整业务，通过配置就能实现逻辑。并且是透明可视化的操作，马上就要面市了。我们现在正在做beta测试，有4个体验客户，也许奥运会后你就可以看到，呵呵 [/quote]
:) 给个beta版说明看哈撒！
2008-7-21 10:09
szeng19
[quote]原帖由 [i]hpls[/i] 于 2008-7-18 21:52 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10996859&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
szeng19 的这个观点我很赞同，但是现在平台市场 疑似这样的产品很多，而且都貌似如此定位，为了能让客户接受又冠以很多新的名词来混淆客户的注意力，当技术本质被营销手段虚化那就太可怕了，希望大家都能擦亮眼睛啊！
这点我不是很赞同，平台的定位是业务需求的描述工具，业务软件的生成工具，这和成熟的应用软件有很大的区别，既然定位是平台就不要去和具有多行业解决方案的应用系统去对比案例，就像成熟应用系统不会和你比技术架构，这两者没有可比性。
而且既然是平台，那么随着客户的使用，你还怕没有案例，所有客户应用後生成的业务软件都是案例，只要平台提供很好的导入导出工具，实现业务模型和生成的应用系统之间的可逆，我想没有那个应用产品能比得上。就像很多软件开发者会围绕软件开发工具开发很多控件一样，平台的使用者也同样可以共享自己的业务模型供大家去交流使用。
ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！ [/quote]
谢谢这位朋友的关注。针对第二点的回复，我也曾经有过。说实话，平台都会走过这个阶段，首先认为自己找到了银弹，疯狂的研究技术和构件本身，创建了一大堆貌似强大的平台构件。但在使用和推广时，往往遭遇瓶颈。这是一个公司战略问题，我们也看到国内还有很多公司在这个泥潭中苦苦挣扎。客户对平台会有一定的兴趣，但谁也不愿意吃第一只螃蟹。这时，成功案例显得非常重要。国内的平台软件，最缺乏的其实就是成功案例。其次，我们强调的是业务平台，不是纯粹的技术平台。站在营销的角度，客户买的是你的服务，买的的是咨询和管理思想。业务平台是面向最终客户的，而不是开发公司（当然，也不乏这样的软件，做出来只能卖给开发或者实施商做二次定制）。卖软件，其实卖的是咨询和服务。软件本身甚至可以免费，但咨询不打折。这也是我们秉承的原则。
至于提到的业务模型和应用系统之间的可逆变化，这点的确非常关键。正如我前面所说，重点在于咨询。在售前和咨询步骤完成的业务模型，能够很快的映射为应用模型，这一点上我们的系统已经达到，不过限于商业机密，不便透露细节。有兴趣，可以来信交流，或者看看供应链仿真模块，我们参与的一些讨论。
平台不是技术玩票，不是营销操作，平台要给用户带来更大的客户价值！
szeng19 的这个观点我很赞同，但是现在平台市场 疑似这样的产品很多，而且都貌似如此定位，为了能让客户接受又冠以很多新的名词来混淆客户的注意力，当技术本质被营销手段虚化那就太可怕了，希望大家都能擦亮眼睛啊！
这点我不是很赞同，平台的定位是业务需求的描述工具，业务软件的生成工具，这和成熟的应用软件有很大的区别，既然定位是平台就不要去和具有多行业解决方案的应用系统去对比案例，就像成熟应用系统不会和你比技术架构，这两者没有可比性。
而且既然是平台，那么随着客户的使用，你还怕没有案例，所有客户应用後生成的业务软件都是案例，只要平台提供很好的导入导出工具，实现业务模型和生成的应用系统之间的可逆，我想没有那个应用产品能比得上。就像很多软件开发者会围绕软件开发工具开发很多控件一样，平台的使用者也同样可以共享自己的业务模型供大家去交流使用。
ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！ [/quote]
谢谢这位朋友的关注。针对第二点的回复，我也曾经有过。说实话，平台都会走过这个阶段，首先认为自己找到了银弹，疯狂的研究技术和构件本身，创建了一大堆貌似强大的平台构件。但在使用和推广时，往往遭遇瓶颈。这是一个公司战略问题，我们也看到国内还有很多公司在这个泥潭中苦苦挣扎。客户对平台会有一定的兴趣，但谁也不愿意吃第一只螃蟹。这时，成功案例显得非常重要。国内的平台软件，最缺乏的其实就是成功案例。其次，我们强调的是业务平台，不是纯粹的技术平台。站在营销的角度，客户买的是你的服务，买的的是咨询和管理思想。业务平台是面向最终客户的，而不是开发公司（当然，也不乏这样的软件，做出来只能卖给开发或者实施商做二次定制）。卖软件，其实卖的是咨询和服务。软件本身甚至可以免费，但咨询不打折。这也是我们秉承的原则。
至于提到的业务模型和应用系统之间的可逆变化，这点的确非常关键。正如我前面所说，重点在于咨询。在售前和咨询步骤完成的业务模型，能够很快的映射为应用模型，这一点上我们的系统已经达到，不过限于商业机密，不便透露细节。有兴趣，可以来信交流，或者看看供应链仿真模块，我们参与的一些讨论。
平台不是技术玩票，不是营销操作，平台要给用户带来更大的客户价值！
2008-7-21 11:51
luoxiang_sh
[quote]原帖由 [i]szeng19[/i] 于 2008-7-21 10:09 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11012907&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
谢谢这位朋友的关注。针对第二点的回复，我也曾经有过。说实话，平台都会走过这个阶段，首先认为自己找到了银弹，疯狂的研究技术和构件本身，创建了一大堆貌似强大的平台构件。但在使用和推广时，往往遭遇瓶颈。这是一个公司战略问题，我们也看到国内还有很多公司在这个泥潭中苦苦挣扎。客户对平台会有一定的兴趣，但谁也不愿意吃第一只螃蟹。这时，成功案例显得非常重要。国内的平台软件，最缺乏的其实就是成功案例。其次，我们强调的是业务平台，不是纯粹的技术平台。站在营销的角度，客户买的是你的服务，买的的是咨询和管理思想。业务平台是面向最终客户的，而不是开发公司（当然，也不乏这样的软件，做出来只能卖给开发或者实施商做二次定制）。卖软件，其实卖的是咨询和服务。软件本身甚至可以免费，但咨询不打折。这也是我们秉承的原则。
至于提到的业务模型和应用系统之间的可逆变化，这点的确非常关键。正如我前面所说，重点在于咨询。在售前和咨询步骤完成的业务模型，能够很快的映射为应用模型，这一点上我们的系统已经达到，不过限于商业机密，不便透露细节。有兴趣，可以来信交流，或者看看供应链仿真模块，我们参与的一些讨论。
平台不是技术玩票，不是营销操作，平台要给用户带来更大的客户价值！ [/quote]
[size=4][color=navy]楼上的说得很好！[/color][/size]
[size=4][color=navy]顶点的LiveBOS平台实际上就是在做这样的事情：给用户或者合作伙伴（开发商、咨询公司）充分的时间和精力去考虑业务模型如何建立，而不是将有限的人员和财力投入到无休止的需求交流、开发、测试、验证等环节。[/color][/size]
[size=4][color=navy]针对用户业务直接建立对象模型，所见即所得的需求验证方式能够极大的降低开发成本、缩短开发周期，更好的提高用户使用满意度。[/color][/size]
[size=4][color=#000080]换言之，我们更加注重的是开发者的系统分析能力而不是写代码的水平有多么高超，我想也许这样才能够符合楼主最后那句话：“[size=2][color=#000000]ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！[/color][/size]”[/color][/size]
[size=4][color=navy][/color][/size]
谢谢这位朋友的关注。针对第二点的回复，我也曾经有过。说实话，平台都会走过这个阶段，首先认为自己找到了银弹，疯狂的研究技术和构件本身，创建了一大堆貌似强大的平台构件。但在使用和推广时，往往遭遇瓶颈。这是一个公司战略问题，我们也看到国内还有很多公司在这个泥潭中苦苦挣扎。客户对平台会有一定的兴趣，但谁也不愿意吃第一只螃蟹。这时，成功案例显得非常重要。国内的平台软件，最缺乏的其实就是成功案例。其次，我们强调的是业务平台，不是纯粹的技术平台。站在营销的角度，客户买的是你的服务，买的的是咨询和管理思想。业务平台是面向最终客户的，而不是开发公司（当然，也不乏这样的软件，做出来只能卖给开发或者实施商做二次定制）。卖软件，其实卖的是咨询和服务。软件本身甚至可以免费，但咨询不打折。这也是我们秉承的原则。
至于提到的业务模型和应用系统之间的可逆变化，这点的确非常关键。正如我前面所说，重点在于咨询。在售前和咨询步骤完成的业务模型，能够很快的映射为应用模型，这一点上我们的系统已经达到，不过限于商业机密，不便透露细节。有兴趣，可以来信交流，或者看看供应链仿真模块，我们参与的一些讨论。
平台不是技术玩票，不是营销操作，平台要给用户带来更大的客户价值！ [/quote]
[size=4][color=navy]楼上的说得很好！[/color][/size]
[size=4][color=navy]顶点的LiveBOS平台实际上就是在做这样的事情：给用户或者合作伙伴（开发商、咨询公司）充分的时间和精力去考虑业务模型如何建立，而不是将有限的人员和财力投入到无休止的需求交流、开发、测试、验证等环节。[/color][/size]
[size=4][color=navy]针对用户业务直接建立对象模型，所见即所得的需求验证方式能够极大的降低开发成本、缩短开发周期，更好的提高用户使用满意度。[/color][/size]
[size=4][color=#000080]换言之，我们更加注重的是开发者的系统分析能力而不是写代码的水平有多么高超，我想也许这样才能够符合楼主最后那句话：“[size=2][color=#000000]ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！[/color][/size]”[/color][/size]
[size=4][color=navy][/color][/size]
2008-7-22 15:38
szeng19
[quote]原帖由 [i]luoxiang_sh[/i] 于 2008-7-21 11:51 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11014454&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
楼上的说得很好！
顶点的LiveBOS平台实际上就是在做这样的事情：给用户或者合作伙伴（开发商、咨询公司）充分的时间和精力去考虑业务模型如何建立，而不是将有限的人员和财力投入到无休止的需求交流、开发、测试、验证等环节。
针对用户业务直接建立对象模型，所见即所得的需求验证方式能够极大的降低开发成本、缩短开发周期，更好的提高用户使用满意度。
换言之，我们更加注重的是开发者的系统分析能力而不是写代码的水平有多么高超，我想也许这样才能够符合楼主最后那句话：“ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！”
[/quote]
开发人员就是需要不断的提升自己的认识高度。不管平台厂商或者公司如何要求，都要透过表面现象去深入研究一些不变的东西。语言只是工具，模式是关键。平台也只是工具，实现的业务模型才是关键。
楼上的说得很好！
顶点的LiveBOS平台实际上就是在做这样的事情：给用户或者合作伙伴（开发商、咨询公司）充分的时间和精力去考虑业务模型如何建立，而不是将有限的人员和财力投入到无休止的需求交流、开发、测试、验证等环节。
针对用户业务直接建立对象模型，所见即所得的需求验证方式能够极大的降低开发成本、缩短开发周期，更好的提高用户使用满意度。
换言之，我们更加注重的是开发者的系统分析能力而不是写代码的水平有多么高超，我想也许这样才能够符合楼主最后那句话：“ps：希望平台厂商都能这么设计产品架构，那么我们这些开发者可是太幸福了！再不用去不断学习语言了，只需要练就一身系统分析和设计的本领万事大吉了！”
[/quote]
开发人员就是需要不断的提升自己的认识高度。不管平台厂商或者公司如何要求，都要透过表面现象去深入研究一些不变的东西。语言只是工具，模式是关键。平台也只是工具，实现的业务模型才是关键。
2008-7-24 23:29
清风车影135
看了一下，livbos确实有点特别，感觉是MDA与DSL的实践，如果真正实现了，应该是不错的东西，但为何只有java平台的，其实完全也可以做.net下的啊。既然java平台实现了。net应该更加简单才对
2008-7-25 09:42
szeng19
[quote]原帖由 [i]清风车影135[/i] 于 2008-7-24 23:29 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11058567&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
看了一下，livbos确实有点特别，感觉是MDA与DSL的实践，如果真正实现了，应该是不错的东西，但为何只有java平台的，其实完全也可以做.net下的啊。既然java平台实现了。net应该更加简单才对 [/quote]
继续楼上的反问，为什么只有java和.net才能做呢？ 呵呵
平台更多的是一个思维方式，与具体语言无关的。即使只用excel也可以做平台产品，呵呵
看了一下，livbos确实有点特别，感觉是MDA与DSL的实践，如果真正实现了，应该是不错的东西，但为何只有java平台的，其实完全也可以做.net下的啊。既然java平台实现了。net应该更加简单才对 [/quote]
继续楼上的反问，为什么只有java和.net才能做呢？ 呵呵
平台更多的是一个思维方式，与具体语言无关的。即使只用excel也可以做平台产品，呵呵
2008-7-26 17:22
hawk_e2e
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
2008-7-28 10:15
szeng19
[quote]原帖由 [i]hawk_e2e[/i] 于 2008-7-26 17:22 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11080182&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。 [/quote]
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。 [/quote]
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
2008-7-30 00:01
hawk_e2e
QUOTE:原帖由 hawk_e2e 于 2008-7-26 17:22 发表
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
-------------------------------------------------------------------------------------------------------------
洗耳恭听！
还有一家，深圳极致平台，也蛮有特点的。
其实从细节还是可以看出产品的水平。
能不能算平台不是最重要，要紧的是水平，水平差的平台不会比直接用开发工具好多少。
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
-------------------------------------------------------------------------------------------------------------
洗耳恭听！
还有一家，深圳极致平台，也蛮有特点的。
其实从细节还是可以看出产品的水平。
能不能算平台不是最重要，要紧的是水平，水平差的平台不会比直接用开发工具好多少。
2008-7-30 10:43
szeng19
[quote]原帖由 [i]hawk_e2e[/i] 于 2008-7-30 00:01 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11107087&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
QUOTE:原帖由 hawk_e2e 于 2008-7-26 17:22 发表
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
-------------------------------------------------------------------------------------------------------------
洗耳恭听！
还有一家，深圳极致平台，也蛮有特点的。
其实从细节还是可以看出产品的水平。
能不能算平台不是最重要，要紧的是水平，水平差的平台不会比直接用开发工具好多少。 [/quote]
现在软件的差异多数体现在细节上。为什么好的管理软件要卖那么贵，也是细节处理得好。细节决定成败
QUOTE:原帖由 hawk_e2e 于 2008-7-26 17:22 发表
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。
解释性语句，运行时解释并执行
效率问题关键是构架设计，该编译的编译，该灵活的灵活
类似于.net的基础构架，在第一次运行.net 的时候，都很慢，因为要现编译，呵呵...
不过，这里的运行效率并不是一个关键问题，我们不要限制自己的思维，从更高和全局的角度思考问题
-------------------------------------------------------------------------------------------------------------
洗耳恭听！
还有一家，深圳极致平台，也蛮有特点的。
其实从细节还是可以看出产品的水平。
能不能算平台不是最重要，要紧的是水平，水平差的平台不会比直接用开发工具好多少。 [/quote]
现在软件的差异多数体现在细节上。为什么好的管理软件要卖那么贵，也是细节处理得好。细节决定成败
2008-7-30 15:15
Ryan-liumin
[quote]原帖由 [i]szeng19[/i] 于 2008-7-30 10:43 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11109532&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
现在软件的差异多数体现在细节上。为什么好的管理软件要卖那么贵，也是细节处理得好。细节决定成败 [/quote]
:right:
现在软件的差异多数体现在细节上。为什么好的管理软件要卖那么贵，也是细节处理得好。细节决定成败 [/quote]
:right:
2008-8-1 11:17
luoxiang_sh
[quote]原帖由 [i]hawk_e2e[/i] 于 2008-7-26 17:22 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11080182&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。 [/quote]
[size=3][color=navy]谢谢你的关注，但感觉你还是按辅助软件开发平台的观点来看我们的LiveBOS业务结构平台：
1.我们认为在真正的业务结构平台，不需要直接进行数据库设计，数据库不过是我们对象的永久化保存而已，我们的业务对象设计完成后，部署时，会自动在数据库中，生成对应的表，而一个业务对象，可能没有表（如虚拟对象），也可能有1个表，2个表，或3个表....
至于界面，对于我对象的展现，对象设计时，通过定义展现属性即可。
2. LiveBOS的画图设计，实际是我们的对象流程设计，按bpel规范实现业务逻辑。如果逻辑及其复杂，是有点麻烦，但我们认为在业务模型上设计的已经很少涉及细节的底层程序控制了，所以应该很少有十分复杂的逻辑控制。
3. 效率问题，当然是经过实际的验证才更能说明问题。我可以很负责任的说：平台本身在对象数据，表达解析的cache上做了大量优化工作。在实际的业务应用中，表现是令人十分满意的。[/color][/size]
[[i] 本帖最后由 luoxiang_sh 于 2008-8-1 12:00 编辑 [/i]]
我也看了下LIVEBOS的演示，还可以，呵呵。
可以算是平台，虽然不是很强大，哈哈。
就象尝了道菜，有些话要说：
1.为啥没有数据库设计工具和界面设计工具？
2.IF ELSE都要画图来实现有点花俏，如果逻辑复杂岂不是要画很多图？
3.中间语言估计是配置性语言，也就是说这种语言写的代码最终不会编译成JAVA，也不会解释成JAVA。
会由内部的运行机制来解析执行，对吧？
但当遇到业务逻辑很复杂的模块时，怀疑其运行效率。 [/quote]
[size=3][color=navy]谢谢你的关注，但感觉你还是按辅助软件开发平台的观点来看我们的LiveBOS业务结构平台：
1.我们认为在真正的业务结构平台，不需要直接进行数据库设计，数据库不过是我们对象的永久化保存而已，我们的业务对象设计完成后，部署时，会自动在数据库中，生成对应的表，而一个业务对象，可能没有表（如虚拟对象），也可能有1个表，2个表，或3个表....
至于界面，对于我对象的展现，对象设计时，通过定义展现属性即可。
2. LiveBOS的画图设计，实际是我们的对象流程设计，按bpel规范实现业务逻辑。如果逻辑及其复杂，是有点麻烦，但我们认为在业务模型上设计的已经很少涉及细节的底层程序控制了，所以应该很少有十分复杂的逻辑控制。
3. 效率问题，当然是经过实际的验证才更能说明问题。我可以很负责任的说：平台本身在对象数据，表达解析的cache上做了大量优化工作。在实际的业务应用中，表现是令人十分满意的。[/color][/size]
[[i] 本帖最后由 luoxiang_sh 于 2008-8-1 12:00 编辑 [/i]]
2008-8-1 22:45
hawk_e2e
业务平台都不能算新事物了，做得好还是很强大的，为啥ITPUB不设专题来交流？
对于MIS、ERP这些，很多人都说软件（包括技术、人员等）不重要，它好像不是最重要，但
不知有没有说错，大多数ERP失败都在软件上集中体现。
买个房子，无论怎么不好起码可以住，但买个ERP为啥会出现失败？失败是不是代表不能使用？
不能使用应不应该退货？
对于MIS、ERP这些，很多人都说软件（包括技术、人员等）不重要，它好像不是最重要，但
不知有没有说错，大多数ERP失败都在软件上集中体现。
买个房子，无论怎么不好起码可以住，但买个ERP为啥会出现失败？失败是不是代表不能使用？
不能使用应不应该退货？
2008-8-3 14:29
szeng19
[quote]原帖由 [i]hawk_e2e[/i] 于 2008-8-1 22:45 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=11141528&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
业务平台都不能算新事物了，做得好还是很强大的，为啥ITPUB不设专题来交流？
对于MIS、ERP这些，很多人都说软件（包括技术、人员等）不重要，它好像不是最重要，但
不知有没有说错，大多数ERP失败都在软件上集中体现。
买个房子，无论怎么不好起码可以住，但买个ERP为啥会出现失败？失败是不是代表不能使用？
不能使用应不应该退货？ [/quote]
国内很多企业上erp很盲目。自身的条件和环境，上一个进销存系统可能效率更高，效果更好。硬要上erp，搞得水土不服。erp项目失败后，很多情况就是尾款收不到，这对于软件厂商和客户都是很大的损失。软件提供商直接做企业咨询本来就有一点王婆卖瓜的嫌疑，呵呵。国内专业的管理软件咨询业发展还不是很好，这也是我们致力在做的事情。我们的理念是量体裁衣，软件随企业的发展而发展，增加更多的柔性。而不是带有‘革命’色彩的erp改造，体质不好的人不宜大补....
业务平台都不能算新事物了，做得好还是很强大的，为啥ITPUB不设专题来交流？
对于MIS、ERP这些，很多人都说软件（包括技术、人员等）不重要，它好像不是最重要，但
不知有没有说错，大多数ERP失败都在软件上集中体现。
买个房子，无论怎么不好起码可以住，但买个ERP为啥会出现失败？失败是不是代表不能使用？
不能使用应不应该退货？ [/quote]
国内很多企业上erp很盲目。自身的条件和环境，上一个进销存系统可能效率更高，效果更好。硬要上erp，搞得水土不服。erp项目失败后，很多情况就是尾款收不到，这对于软件厂商和客户都是很大的损失。软件提供商直接做企业咨询本来就有一点王婆卖瓜的嫌疑，呵呵。国内专业的管理软件咨询业发展还不是很好，这也是我们致力在做的事情。我们的理念是量体裁衣，软件随企业的发展而发展，增加更多的柔性。而不是带有‘革命’色彩的erp改造，体质不好的人不宜大补....
2008-8-12 12:52
清风车影135
什么是业务平台？ 现在业绩根本就不存在一致的说法，现在是各产商为了商业利益，各取所需，所以没有什么好比较的。
2008-8-14 14:40
hpls
如果按照楼上的意思是大家各有千秋，无法做出选择了？
我觉得总会具有可比性，只是大家选择的标准不同罢了。也就是说，根据自身发展的业务需要来选择最适合自己的产品。
实际上发这个帖子的本意在于期望有高人能够对各家系统加以分析，并给出相应的选择建议。
期待更多的回复。。。。。
我觉得总会具有可比性，只是大家选择的标准不同罢了。也就是说，根据自身发展的业务需要来选择最适合自己的产品。
实际上发这个帖子的本意在于期望有高人能够对各家系统加以分析，并给出相应的选择建议。
期待更多的回复。。。。。
页: 1 [2] 3
查看完整版本: 业务平台，马，驴，骡子？（请求斑竹置顶）
Powered by ITPUB论坛