对普元及其EOS产品的一些了解

我所供职的是一家小的行业咨询公司，关注普元有一段时间了.对普元及EOS的了解是今年初从几个同事那开始的。这些同事有HP、CMCC、CMCB、...等等。他们是普元EOS的最终用户，他们对普元的评价是：“三流的产品、二流的开发、一流的市场”。说白了，就是产品不咋滴，研发员工也一般，但市场人员是一流的。不过，据个人观察，所谓的一流市场，不过是甲方高层的攻关；另外就是烧钱造势(其实也没花多少钱)，到处开会，以求混个脸熟。
我对部分EOS集成商的开发人员进行过调查,以下是调查反馈：
1. 从技术角度及员工发展角度看，EOS是技术的畸形儿，使用它的人，感觉自己的择业竞争力在一点点消失。换名话说，EOS在断送开发人员前途。据说这是一家合作公司开发人员离职率奇高的原因之一；
2. 从业务角度看，EOS与其所吹嘘的SOA相差千里，所谓构件其实就是将一些java的方法进行了包装，改头换面成图元方式进行调用，更恶心的是其中到处过度使用的XML。XML的过度使用，使EOS的开发丧失了java言语天生的优点;
3. 从工具角度看，EOS充其量是一个开发平台，不是其所吹嘘的SOA业务平台，所有的业务开发不能提供任何可用的业务框架。都要EOS可怜的开发人员进行血和泪的总结后，再开发。
4. 从系统角度看，EOS上开发的东西无任何移值的可能，你在EOS上开发了一个满意的模块，想使用到其它非EOS项目中，是完全不可能的。这对一个想做积累的公司或个人来说是个灾难。

说了这么几个点，其实EOS也有不错的地方，比如构件可以极为方便地发布为webservice、可以较为方便地开发简单的基于数据库的web应用（查询、更新数据）;另外抛开EOS平台,单看他的流程引擎的设计在市场上也绝对是一流的。

此外,作为民族软件,也有相当的人喜欢EOS。普元当前产品线还没有进入盈利阶段,所有的市场动作均为造势。而EOS对国人来说，萝卜白菜各有所爱，本人希望EOS的路越走越宽。
以上是对EOS的调查总结,不代表本人观点。

评论

14 楼 funnywiser 2009-05-02  

我们也做开发平台，确实有几个问题需要考虑：
1、如何真正的对开发人员有提高
    很多手段和技术来保证提高工作效率，也有很多方法可以生成一个快速的系统。看国内现在这个多web快速开发平台就知道。但是开发平台最终是给开发人员用的。如何保证开发人员使用这个平台之后，以后的价值是会逐渐提高的。SAP其实也是一套独立的开发平台，其为什么能够快速的推广出来，关键还是SAP顾问和开发的工资很高，让技术人员愿意自己掏钱去学。
    如果开发平台最终会降低开发人员的价值。那最终只会使这个平台被开发人员放弃。
    我们最初在做开发平台也碰到这样的问题，最终我们发现，开发人员价值的提升其实不是编码的提升，而是分析设计能力、项目管理能力、更高要求的编码能力的提升。
    像我们开发平台，完全不用编码就可以实现业务逻辑层、数据库层以及界面的生成。很多简单的项目，都不需要编码了。以前一个人能最多只能做一个模块中一部分代码的工作，现在可以管理几个项目模块的实现，并且会需要分析数据库如何设计以及界面如何布局等各种问题。也就是说原来技术人员的面更广了，对其业务分析能力、设计能力以及整个项目管理能力是一个全面的锻炼。而这些能力原先是必须做到系统分析员才可能去锻炼的。
    另外编码能力并不是说完全不需要用，平台只是一个复用一些组件的工具。那么如何设计和实现优秀的组件，是需要编码实现之后，扩充到平台中的。这是更高层次的编码能力。
2、如何标准化，并且和其他的框架集成
    技术更新换代，自己的平台可能在某些方面可以一直保持领先地位，但是并不是所有方面都能领先。就像XML技术，当初推出的时候，很多人觉得配置XML比开发程序容易多了。但是现在很多框架用了XML配置之后，发现还不如直接写程序的类来的方便。现在智能化的编辑器可以自动生成大量的代码，以及优秀的纠错能力。XML反而变得更麻烦了，而且性能也成问题。
    因此要充分利用多个框架的技术，最好能轻易的集成其他的框架，或者来一种更好的实现。这样就是一个开发的系统。
3、复用性非常关键
    我们做技术的，用的最多的是复制、粘贴。这是一个最简单的复用的例子，并不是说一定要设计完全通用的组件化，才是复用的一种。
    开发平台能不能简单的将一些东西，完全进行复制、粘贴是衡量一个工具易用性的一个非常重要的指标。

13 楼 bease 2008-10-29  

pengzhou 写道

客观的看，普元是国内为数不多肯耗费人力，物力从事基础软件开发的公司，也做出了一些成绩，当然产品是否已经得到公认或开发人员的认可是另一会事。这种务实的精神是值得赞扬的，只有国内象他们、东方通、金碟这样的公司多了，我们才不会继续每个大项目都看着老外吃饭，我们喝汤的惨景。

同意,但我觉得这更应当是倔吧.

12 楼 pengzhou 2008-10-28  

客观的看，普元是国内为数不多肯耗费人力，物力从事基础软件开发的公司，也做出了一些成绩，当然产品是否已经得到公认或开发人员的认可是另一会事。这种务实的精神是值得赞扬的，只有国内象他们、东方通、金碟这样的公司多了，我们才不会继续每个大项目都看着老外吃饭，我们喝汤的惨景。

11 楼 andy54321 2008-10-28  

upheart 写道

EOS如果能以实用主义的态度来发展，而不被为了市场和概念而牵引的话，可能会做的更好。如果什么都往构建上靠，那就是手拿一把锤子看什么都是钉子了。如果什么问题都试图都用图形化来解决，那就是把简单的问题复杂化了。如果试图让傻瓜而不是程序员来写出程序来，那写出的只能是傻瓜程序。

嘿嘿....

10 楼 honno 2008-10-28  

普元要真正实现“SOA从构件开始”这一概念，还有很长的路要走。个人认为，要实施SOA，根据目前的技术发展来看，还需要ESB,MQ,BPM的基础设施产品的大力支持。而普元目前没有ESB,MQ这方面的产品为其提供支持。使用EOS开发应用系统还是有一定的实际价值，比较借助其开发平台在一定程度上缩短了开发时间。

9 楼 bease 2008-10-28  

cryolite 写道

以上是对EOS的调查总结,不代表本人观点。-----------------------------------------------这句话有逻辑矛盾吧

嘿嘿,对,确实有点矛盾。
不过声明一下：我总不能把跟人家闲聊的东西都贴上吧。呵呵。

8 楼 cryolite 2008-10-28  

以上是对EOS的调查总结,不代表本人观点。

-----------------------------------------------
这句话有逻辑矛盾吧

7 楼 bease 2008-10-28  

框架只是帮助人们的

Azi 写道

要写好程序，关键还是理论，实际掌握。框架只是帮助人们的

我也是开发人员出身，对大多数中低水平的开发人员来说，谈理论与给一个好的框架或平台他们，就像梦中的美食与眼前的馒头一样。当然，如果理论能让兄弟们正常下班，我是非常乐意的。
我认为，任何方法或理论最终只有转化为生产效力才是其归属，这种归属我比较赞成的不光是理论文档、不光是高空言语，而且还包括能提高效率的生产工具。这是我认为经验传承过程中的“沉淀”方式。
嘿嘿，写完之后，我回头再审视上面这几句，发现我自己也在谈理论，也是高谈。BS一下。

6 楼 bease 2008-10-28  

liu_swei 写道

普元的服务器试用过几次 感觉比中创的服务器强多了 国产的中间件都不怎么样 就是相互抄袭，就是看谁抄袭的高明看谁骗国家的钱骗的更容易 现在国家大力支持国产中间件，钱太容易骗了

嘿嘿,对,普元确实得了不少国家的￥支持。有几次开会还有国家XX司的某XXX露面。另外，你拿普元与中创比，虽然当下是矮子与矮子之间的事，但也许普元会认为是对其的侮辱，毕竟，普元的定位是很清高的。

5 楼 bease 2008-10-28  

EOS的东西,说实话我是看不懂的.
有以下几个问题一直不能够理解:
1.EOS要解决的问题是什么?
2.EOS解决这些问题的思路是什么？
3.EOS解决问题的优势何在，劣势何在?

liujunsong 写道

EOS的东西,说实话我是看不懂的. 有以下几个问题一直不能够理解: 1.EOS要解决的问题是什么? 2.EOS解决这些问题的思路是什么？ 3.EOS解决问题的优势何在，劣势何在?

这几个问题普元的同学更有说话权,不过个人片面理解:EOS Studio是一个WEB/流程开发框架,就像strus+hibernate一样,而EOS部署运行时,就是一个流程运行平台了.

4 楼 liujunsong 2008-10-28  

EOS的东西,说实话我是看不懂的.
有以下几个问题一直不能够理解:
1.EOS要解决的问题是什么?
2.EOS解决这些问题的思路是什么？
3.EOS解决问题的优势何在，劣势何在?

3 楼 liu_swei 2008-10-28  

普元的服务器试用过几次
感觉比中创的服务器强多了
国产的中间件都不怎么样
就是相互抄袭，就是看谁抄袭的高明看谁骗国家的钱骗的更容易
现在国家大力支持国产中间件，钱太容易骗了

2 楼 Azi 2008-10-28  

要写好程序，关键还是理论，实际掌握。框架只是帮助人们的

1 楼 upheart 2008-10-27  

EOS如果能以实用主义的态度来发展，而不被为了市场和概念而牵引的话，可能会做的更好。
如果什么都往构建上靠，那就是手拿一把锤子看什么都是钉子了。
如果什么问题都试图都用图形化来解决，那就是把简单的问题复杂化了。
如果试图让傻瓜而不是程序员来写出程序来，那写出的只能是傻瓜程序。