业务平台，马，驴，骡子？（请求斑竹置顶）

最近中心要选一个业务架构平台，要我们考察。

但看了许多产品，感觉现在这类产品差别太大了，无论是[url=http://www.primeton.com/]EOS[/url]还是[url=http://www.livebos.com]LiveBOS[/url]，还是[url=http://www.justep.com/]起步[/url]，完全无法真正放在一起比较：eos更像一套软件开发的方法加上统一的技术架构，要学习的细节很多，有点费劲。livebos很特别，连数据库的设计都不要了，感觉是把C++的类思想，直接在业务层面实现了，与原来的开发思路差别有点大了，用起来得改换思路。起步的东西呢，感觉更接近应用，但技术上有点怪，既不是JAVA，也不是.net,竟然是delphi，
所以感觉这东西不是那个也不是最好的选择了，甚至该不该用，都是问题。

请教一下各位大侠的看法？




PS：各平台厂家的也可以来交流交流哦！

[[i] 本帖最后由 hpls 于 2008-7-18 22:07 编辑 [/i]]

[font=宋体][size=3]业务架构中间件与辅助开发平台的差异[/size][/font]
[font=宋体][size=3]在整个软件开发项目的过程中，都要经历在软件需求分析、系统设计、系统实现的过程，即使我们采用了组件化的开发、面向对象的设计，还是会发现，分析设计人员、程序员和用户之间，仍然无法沟通的很好，应用系统在交付用户使用时，仍然离用户的真实意图比较远。这是因为，提出需求的用户和系统设计的技术人员看问题的角度不同。[/size][/font]
[size=3][font=宋体]用户是从业务的角度，提出应用软件是哪个职能范围的、有哪些应用模块、每个模块又有哪些子模块，这是一种基于[/font][font=Times New Roman]“[/font][font=宋体]业务对象[/font][font=Times New Roman]”[/font][font=宋体]的描述方法。而开发人员则是从技术的角度，架构是什么？数据库的结构是什么样的？表间关系是什么？业务逻辑如何编写？页面展现如何设计？这是传统的[/font][font=Times New Roman]“[/font][font=宋体]组件[/font][font=Times New Roman]”[/font][font=宋体]或[/font][font=Times New Roman]“[/font][font=宋体]构件[/font][font=Times New Roman]”[/font][font=宋体]思路。所以，用户和开发人员之间沟通起来仍然很难，业务实现及业务调整都依然为软件开发项目带来很大的难度和不可控因素。[/font][/size]
[font=宋体][size=3]而对应与应用系统实现，软件开发平台为了解决这些问题，经历了语言级开发到辅助开发平台的升级，直到我们所提供的面向业务架构的中间件平台。[/size][/font]
[font=宋体][size=3]而辅助开发平台源自与语言级软件开发环境，是从软件项目框架和程序开发过程各环节的开发效率上增加了许多特色的工具，从而为开发团队、开发者提供了更为高效的开发工具和项目控制与组织管理的手段，最终为整个项目降低了开发成本，提高了开发效率，但这并未真正意义上解决上面的问题。[/size][/font]
[size=3][font=宋体]例如：基于软件辅助开发平台，我们依然遵循需求分析，数据库建模，业务逻辑建模，页面设计，调试跟踪，测试，发布等过程，但是在每个节点上辅助开发工具都会提供相应厂商所特有的[/font][font=Times New Roman]“[/font][font=宋体]可视化工具[/font][font=Times New Roman]”[/font][font=宋体]以减低过程的操作难度，提升开发效率。[/font][/size]
[size=3][font=宋体]我们从软件系统开发实现的过程来看，开发人员会按照调研的需求分析报告，按照数据库建模，业务逻辑建模，页面设计的过程对业务需求进行分层的计算机语言转化，然后再将业务逻辑与物理数据库、展现页面与业务逻辑之间建立映射关系，之后在开始跟踪调试，最终发布应用程序。在这整个过程中程序员会利用辅助开发平台的[/font][font=Times New Roman]“[/font][font=宋体]可视化工具[/font][font=Times New Roman]”[/font][font=宋体]进行配置和关联，去自动生成系统的[/font][font=Times New Roman]70%-80%[/font][font=宋体]的代码，复杂业务逻辑仍需手工代码编写实现。这对开发人员来说确实减低了很大的开发工作量，具体体现在开发过程中的普遍性及通用性的工作量，细节性的复杂业务逻辑处理难度和工作量并没有得到改善，这大概会占[/font][font=Times New Roman]20%-30%[/font][font=宋体]的代码量。[/font][/size]
[size=3][font=宋体]但是软件系统的并不是一成不变的，随着业务需求的升级，软件系统功能及业务处理必须进行同步的更新，例如数据结构上需要增加一个字段，这时就会涉及物理数据库的调整，也会涉及业务逻辑的调整和页面展现的调整等等，当然也包括各层面的映射关系的调整。这时不管是哪个方面的调整都会影响其他层面的设计，而且既可能是通过[/font][font=Times New Roman]“[/font][font=宋体]可视化工具[/font][font=Times New Roman]”[/font][font=宋体]自动生成的代码部分，也可能是自定义的代码部分，而这种虽然只是系统从[/font][font=Times New Roman]1.0[/font][font=宋体]到[/font][font=Times New Roman]1.01[/font][font=宋体]的升级，都需要我们调整这[/font][font=Times New Roman]0.1[/font][font=宋体]的升级部分所涉及的三层调整，以此看来并不是[/font][font=Times New Roman]20%[/font][font=宋体]和[/font][font=Times New Roman]80%[/font][font=宋体]的关系了，而是[/font][font=Times New Roman]100%[/font][font=宋体]的调整。[/font][/size]
[font=宋体][size=3]而面向业务结构的中间件平台又是如何解决上述问题的呢？[/size][/font]
[size=3][font=宋体]业务架构平台是以业务对象建模为核心的业务中间件及其集成开发工具。在它的支持下，应用软件彻底实现[/font][font=Times New Roman]“[/font][font=宋体]业务驱动导向[/font][font=Times New Roman]”[/font][font=宋体]的软件开发模式，并实现[/font][font=Times New Roman]“[/font][font=宋体]应您所需，随时而变[/font][font=Times New Roman]”[/font][font=宋体]的应用系统。基于业务中间件平台，开发者只需要基于业务和管理的层面，而非技术的层面来理解、设计、构架和集成企业的信息系统（基于业务层面是指开发人员只需描述企业的组织机构、业务流程、业务信息、业务资源、业务逻辑、业务事件等业务内容，而不考虑技术层面的东西），就可以实现各类基于[/font][font=Times New Roman]WEB[/font][font=宋体]的高层次的信息化应用。而且，用户可以随时在运行中重新定义或调整业务模型，从而达到使自己的信息系统完全贴近不断变化的业务需求，这也是[/font][font=Times New Roman]“[/font][font=宋体]灵动[/font][font=Times New Roman]”[/font][font=宋体]的价值体现。[/font][/size]
[size=3][font=宋体]在这样的平台里，开发者所关注的就是[/font][font=Times New Roman]“[/font][font=宋体]业务模型[/font][font=Times New Roman]”[/font][font=宋体]，在集成开发环境中通过对[/font][font=Times New Roman]“[/font][font=宋体]业务对象（[/font][font=Times New Roman]BO[/font][font=宋体]）[/font][font=Times New Roman]”[/font][font=宋体]的分析来设计描述模型，而[/font][font=Times New Roman]“[/font][font=宋体]业务模型[/font][font=Times New Roman]”[/font][font=宋体]的处理流程通过[/font][font=Times New Roman]“[/font][font=宋体]业务流程（[/font][font=Times New Roman]BP[/font][font=宋体]）[/font][font=Times New Roman]”[/font][font=宋体]来描述业务对象的逻辑关系，业务模型提交至中间件服务器后自动会生成标准应用系统的三层架构，自动建立关联映射关系。当业务对象调整时，只需要修正业务模型重新提交至服务器，服务器又自动修正应用系统中的每个层面，关联映射关系会自动关联。[/font][/size]
[size=3][font=宋体]通过以上我们可以看出，随着两大主流语言开发工具的发展，辅助开发平台的生存空间将会不断缩小，这主要源自各种辅助开发平台的初衷只是语言级开发工具的补充，事实上这是一厢情愿的做法，从计算机语言的发展趋势来看，它将是主流的语言开发工具的过度品，这种现象在微软[/font][font=Times New Roman].net[/font][font=宋体]架构的[/font][font=Times New Roman]VS[/font][font=宋体]上已经有了较大的体现。而且我们通过对各种辅助开发平台的对比可以看出，其核心的差异主要体现为：一方面业务逻辑分解上的颗粒度粗细不同，组件、构件、服务[/font][font=Times New Roman]……[/font][font=宋体]；另一方面所提供的工具的便捷性不同，可视化、图形化、向导模式、拖拽模式[/font][font=Times New Roman]……[/font][font=宋体]；而这些[/font][font=Times New Roman]“[/font][font=宋体]差异特色[/font][font=Times New Roman]”[/font][font=宋体]都将会在主流语言的开发工具的逐步体现。[/font][/size]
[size=3][font=宋体]而业务架构平台则是在开发工具之上的业务模型描述工具，它与开发工具之间是分工关系，可以基于[/font][font=Times New Roman].net[/font][font=宋体]也可以基于[/font][font=Times New Roman]J2EE[/font][font=宋体]，而且他会随着开发语言的发展而越来越强大，毕竟业务模型的建立永远是在系统开发设计实现之前。[/font][/size]
[size=3][font=Times New Roman]

[/font][/size]

[[i] 本帖最后由 hpls 于 2008-7-18 21:26 编辑 [/i]]

置顶的理由是什么?

同问

希望能够得到更多高人的意见，帮忙解决一下我的困惑。。。 谢谢！

这个理由可能不够:好象还没看出LZ的问题.

帮你UP一下吧.

up一下

呵呵，你说的有一些道理。

选择业务平台，不是看开发是不是要转换思想吧。业务平台也不能和java，.net这种技术架构来比较，更不存在什么“C++的类思想”。我觉得有了问题，首先是思考问题的根源在哪里，问题的本质是什么，而不是寻求现成的答案。你真的考虑清楚选择业务平台的原则了吗？

要回答楼主的问题，其实并不复杂。首先楼主要思考一个问题，产生平台业务软件的原因是什么？
无非就是为了适应多变的业务需求，让软件能够与时俱进，而不需要大规模的重新开发，可以重用之前的模式，通过少量的配置或者扩展开发即可满足客户新的业务需求；另外一方面，就是利用平台软件充分调动客户或者说是业务专家的资源，开发团队提供平台或者说是工具，让业务专家自己完成搭建业务系统，以此来缩小业务和实现之间的鸿沟和沟通不畅。

有了这个因，你就反过来看现在的平台软件能否达到以上的初衷。在此，我所持的观点是，如果平台软件不能让业务专家，也就是有有一点（注意，是一点而不是精通）技术能力并有丰富业务经验的客户使用，那这个平台就很失败。说白了，只不过开发了一个二次的IDE，封装了一些控件或者对象，方便进行二次开发而已。注意这里的用词，是二次开发，并不是简单配置。这样的平台对最终用户来说，意义不大，只是一个技术平台而已，客户要反问，我用这个技术平台对我来说有什么用？？客户价值何在？

另外来说，成熟的业务平台和技术平台的显著不同，就是技术平台专注技术本身，其体系可能比较复杂和完备，但缺乏现成的实例。而成熟业务平台是一个最佳案例的集合，在平台提供的同时，已经有一个最佳案例库供客户可以选择和使用。这方面做得比较好的比如SAP，国内也不乏有公司在做这方面的努力，不过就我个人来看，楼主体积的几个产品都不在此列，呵呵...

楼上说的分析的很到位，现有的各个所谓业务平台都不能做到技术无关性，用你的IDE来诠释他们的产品最为合适不过。

楼上提到sap的开发平台确实非常的强大，但是其还以sap已有的产品的依托，包括国内现在kingdee提出的bos，用友的U9似乎都在走sap的路

而我想是否能找到独立的业务架构平台，非技术平台（ide）也非erp产品的辅助开发平台，而是能真正从业务模型生成业务系统的平台，如果有了这样的平台我们的业务实现就能真正脱离技术层面，脱离标准产品，而且能真正实现个性化需求快速开发和适应变化。

楼上提出这样的想法，初衷是很好的。不过，就我个人的看法，比较难于实现。因为这里是一个两难的境地，一方面业务变化快，并有自身的特性，比如行业，领域（供应链，财务，crm..）方面的约束。用户希望平台能够在基本满足现有需求的情况下，能够很快的，最好是透明的方式解决出现的问题，而不想关注太多的技术细节；一方面业务平台想脱离具体的业务，实现更高层次的抽象，势必要放弃一些业务特殊性。这样要么平台就要做很多的构件，而且是比较细粒度的构件，在运行时根据配置进行动态的组装。粒度一细下来，关系就多了，也增加了复杂性，也就给第一个约束相悖。在此一个比较典型的就是eas，试图用自身平台覆盖尽量多的业务的业务，结果有点四不像。要搭建一个简单业务搞得异常复杂，简单问题复杂化是管理的禁忌。
因此，在这里要掌握好一个度的问题。一方面适当结合业务特性，提供一些比较粗粒度的构件，也就是你提及的sap结合适当的erp业务模型；一方面对根据业务实例化的粗粒度的构件要能够体现充分的灵活性，能够简单的配置达到解决业务问题的效果（因为配置已经根据业务进行了优化）； 更深层次的解决方法，是维护核心平台部分，提供外部接口进行应用系统横向整合（SOA最初提出的原因），当然也不一定非要用soa才能达到此目的，实现方法多了。

欢迎多讨论交流哈

[url]http://www.itpub.net/viewthread.php?tid=1011639[/url]
转帖一个，可以相关看看

我来回答szeng19 的一些观点。
MIS（包括ERP）有以下特点：
1.技术门槛不高。注定要在差异性上体现竞争力，业务平台也是开发工具，在这方面比JAVA、C#等开发工具有着根本性的优势。至于做得怎样就另外再算了。所以平台是方向。
2.站在企业角度，对于中小企业，信息化成本应该跟额外请3个信息化人员差不多，如果平均4000元/人月，15万/年，头一年事多，可能是这个数，随着使用时间越长信息化成本应该越低。当然具体还要看企业的规模和实际情况，但无论如何，动辄上百万，几百万一套系统，即使说得再先进再好，企业都要考虑是否赚得回来。当然政府机关事业单位、国企就无所谓了。
3.平台不仅是降低成本，更重要是提高系统的应变能力，更容易满足企业的实际需要。你作为企业老板，手下一个话头醒尾，行动迅速，跟另一个呆头呆脑，踢一下好久才动。你会选哪个？


平台要做到技术无关、非技术人员都能使用，技术和成本都要求很高，自然要价也会很高。据我所知，真正称得上平台的也就思维加速公司的，金蝶、SAP的严格来讲都不能算是业务平台，开发框架可能恰当些。
对于企业选择业务平台，我的观点：
1.确实能把成本大幅度降下来。
2.功能可以不够强大，实用就行，但质量一定要过关。
3.企业是需要一个能伴随其成长的信息系统。
4.良好的合作关系。

MIS（包括ERP）有以下特点：
1.技术门槛不高。注定要在差异性上体现竞争力，业务平台也是开发工具，在这方面比JAVA、C#等开发工具有着根本性的优势。至于做得怎样就另外再算了。所以平台是方向。
2.站在企业角度，对于中小企业，信息化成本应该跟额外请3个信息化人员差不多，如果平均4000元/人月，15万/年，头一年事多，可能是这个数，随着使用时间越长信息化成本应该越低。当然具体还要看企业的规模和实际情况，但无论如何，动辄上百万，几百万一套系统，即使说得再先进再好，企业都要考虑是否赚得回来。当然政府机关事业单位、国企就无所谓了。
3.平台不仅是降低成本，更重要是提高系统的应变能力，更容易满足企业的实际需要。你作为企业老板，手下一个话头醒尾，行动迅速，跟另一个呆头呆脑，踢一下好久才动。你会选哪个？


平台要做到技术无关、非技术人员都能使用，技术和成本都要求很高，自然要价也会很高。据我所知，真正称得上平台的也就思维加速公司的，金蝶、SAP的严格来讲都不能算是业务平台，开发框架可能恰当些。
对于企业选择业务平台，我的观点：
1.确实能把成本大幅度降下来。
2.功能可以不够强大，实用就行，但质量一定要过关。
3.企业是需要一个能伴随其成长的信息系统。
4.良好的合作关系。


很同意以上的观点，特别是关于选择方面的几点建议
1、中小企业由于处在快速成长期，在不同的阶段有不同的管理模式，也就有不同的管理需求。需要信息化系统灵活应变，最好能够伴随企业的成长而成长
2、功能可以不强大，这句话要解释清楚涉及到很多技术细节。但总体上说，就是我以上说的‘粒度’把握问题，比较考构架师的水平
3、平台的初衷就是要缩小技术和业务的鸿沟，更深层次的意义就是有效整合资源。客户能够成为软件开发，维护和实施的有效资源，保持良好的合作关系有助于平台的完善和最佳案例库的扩充
4、平台的一次开发成本相比之下，比传统软件要高。根据我的经验，大致要高出30%左右。但总体开发成本相对要低很多，这个主要体现在实施二次开发和构件库完善后的快速搭建上。

文中提到的中小企业软件成本的问题，我觉得不能一概而论。根据我们的真实市场调查，15w已经是一个中型企业的承受能力。一般的中小企业，3w左右的标准功能+实施可以勉强接受，6w的平台扩展功能+实施是可以接受的。当然，和使用范围和站点还有关系。sap是好，但就像it业中的奢侈品。生活中需要奢侈品，往往很多技术突破和革新都是高端产品探索出来的。但既然是奢侈品，能够消费的人就不多。我们也不是一味要追求最好最贵的，关键是实用。对于我们中国管理软件业来说，更多的就是需要发挥拿来主义，好的吸取，不好的扬弃。

sap由于体系设计过于严谨，所以在灵活性上有欠缺。不过sap很会搞营销，发挥其行业经验优势，强调按照最佳案例进行实施和规范，变弱势为强势。oracle在灵活性上就要好很多，所以在新业务领域的开展进行很快，不过缺点也就是灵活性带来的不稳定。其实都有长处和短处，看如何最大限度的发挥。
国内不乏做得好的平台软件，起步不错，博科、佳软、时空、英客尔都是业务平台中有一定影响的公司，不过目前是在行业内有知名度，一般客户的认识还比较少，这也是平台软件需要思考的一个问题，如何进行有效的大面积推广和有效复制。
其实我也已经做了6年平台软件构架，其中的问题和优势比较清楚。平台化软件并不是最初想像的银弹，可以解决任何软件工程问题。平台软件最后，其实都落在了实施上，好的软件构架能够有效的支持实施快速解决业务问题。所以，不能光从技术的角度看平台，而应该从需求提出，软件开发，实施满足客户需求整个完整的营销链来看软件平台产品。

[font=宋体][size=5]什么是业务架构平台？ google一下，各个产商都觉得自己是，感觉人人都找到了管理软件的银弹，但实际呢？ 许多不过是个概念而已。（中国IT人都喜欢创造概念:)）
很早年以前，俺就听过大连雅琦，能神奇的生成你所要的管理软件。现在当然更多了，这些软件有没有价值，有点，但自称业务结构平台，或中间件，言过其实了。除了最基本的1，2个表的增删改查，真正涉及稍微复杂点的逻辑哪个平台不需编写代码？哪个比需要开发者知道什么是int，number(n)??  普元要java，起步要delphi， ucml要c#，livebos呢，没有听过什么东东。
真正的业务架构平台，需要是什么呢？真正需要抛弃java，c#,DELH之类的程序语言，应该在高层次上描述业务逻辑。。。但这东西，市场上没有真正看到，,所以马，骡子，驴，一个也没有、、、:cool: ，[/size][/font]

回复 #15 hawk_e2e 的帖子

在我看了，思维加速，现在改名起步了，也根本不是业务架构平台，还行需要开发者写delphi代码，不过工作量少点。。。最少只能算个应用开发框架。。。。

[quote]原帖由 [i]清风车影135[/i] 于 2008-7-17 18:12 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10981664&ptid=1005377][img]http://www.itpub.net/images/common/back.gif[/img][/url]
什么是业务架构平台？ google一下，各个产商都觉得自己是，感觉人人都找到了管理软件的银弹，但实际呢？ 许多不过是个概念而已。（中国IT人都喜欢创造概念:)）
很早年以前，俺就听过大连雅琦，能神奇的生成你所要的管理软件。现在当然更多了，这些软件有没有价值，有点，但自称业务结构平台，或中间件，言过其实了。除了最基本的1，2个表的增删改查，真正涉及稍微复杂点的逻辑哪个平台不需编写代码？哪个比需要开发者知道什么是int，number(n)??  普元要java，起步要delphi， ucml要c#，livebos呢，没有听过什么东东。
真正的业务架构平台，需要是什么呢？真正需要抛弃java，c#,DELH之类的程序语言，应该在高层次上描述业务逻辑。。。但这东西，市场上没有真正看到，,所以马，骡子，驴，一个也没有、、、:cool: ， [/quote]


不幸被你言中，你所希望看到的平台，抛弃java，c#,DELH之类的程序语言，让业务专家真正能够不懂开发语言就能调整业务，通过配置就能实现逻辑。并且是透明可视化的操作，马上就要面市了。我们现在正在做beta测试，有4个体验客户，也许奥运会后你就可以看到，呵呵

不是在帮思维加速做广告。
应该叫业务基础平台，应该有以下特点：
1.产品是从企业角度出发来定位，而不是从开发公司角度出发。
  所以版本管理不需要，UML不需要，单元测试不需要...
  相反，企业管理层需要全方位掌握系统，包括业务逻辑、业务状况、权限、业务调整的日志记录等。
  起步这方面还是做到了，其它大多数平台的公司都没有。
2.有一套面向应用的开发语言。
  比JAVA、DELPHI、C#要高级。我觉得绝大多数的MIS都要开发（需经过分析、设计、编码、测试、维护过程），开发一套业务专家主要通过配置就能完成的平台是不现实，或者是广告。业务专家也需要一定的开发能力。主要通过配置来实现具体应用只会导致开发成本高而系统适应性差。
这方面起步没有，但有这样的影子。况且开发这样一套语言不比开发JAVA等的难度要低。

不过，话说回来，这只是从技术角度来讲。框架也好，平台也好，适用好用就行。
传统的MIS开发主要有两个缺点：
1.要开发的地方，开发周期过长。
2.用户的实际需要能否落实到软件的实现没有一个很好的保证。
象ERP这样复杂的业务，调研开发周期过长，开发出来不十分适用，又要反回去调整，折腾来折腾去，谁都耗不起。
平台能很好解决这问题。