找回密码
 注册账号

QQ登录

只需一步,快速开始

手机号码,快捷登录

手机号码,快捷登录

初学者课程:T3自学|T6自学|U8自学软件下载课件下载工具下载资料:通资料|U8资料|NC|培训|年结积分规则 | 使用常见问题Q&A
知识库:U8 | | NC | U9 | OA | 政务U8|U9|NCC|NC65|NC65客开|NCC客开新手必读 | 任务 | 快速增金币用友QQ群[微信群]
查看: 13361|回复: 29

[转帖] [转]我眼中的U9(2)

  [复制链接]
发表于 2009-6-20 18:48:41 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册账号

×
王文京知道U8辉煌了这么多年,不可能把用友带到下一个10年。所以未来10年,用友要想10个亿,100个亿,就需要一个很重量级的,能代表未来10年技术和应用趋势的产品。
当然,王文京也吃过研发亏。当年王文京另外一个爱将邵凯受命研发面向大型企业,能够集团运行,能够在网上运行,能够和SAP抗衡的产品,那就是一定要是中间件、要是JAVA的NC。NC的研发,时机不当,落地也不当。但那个时期的人们都已经疯狂。为什么?因为那时候是1999年,互联网让大家都迷失了方向。大量程序员出走用友去创业,大量企业争先恐后给自己打.com的标签。互联网经济似乎颠覆了一切,就连老江湖柳传志都动摇了,上了FM365。邵凯受命后,立即打造核心团队,全国搜找行内老手。邵凯确实找到了几个从管理、到阅历、到业务、到运作、到技术开发都很在行的人。但可惜致命的有两个地方:1 当时大家都被互联网速度冲昏头脑大干快干,而且当时软件工程也不太流行,设计模式也没有火起来,于是就打算在凤凰岭封闭3个月就可以OK(事实上,一个重量级的想和SAP抗衡的产品不是这样能出来的)。 2 当时大家根本就没想到用啥大型架构,还按照过去U8的架构走,其实当时在国外中间件已经流行,各种大型企业架构已经流行,但中国还未流行。很多NC团队的人都是过去开发VB之类产品的人,对大型企业架构都不是特别理解,觉得U8的架构就应该可以了。但樊冠军的出现让大家第一次认识到大型架构模型。而樊当时是从和佳(还是佳软,忘了,都是老牌的管理软件商)跳过来的。樊并没有用这套架构作过真实的一个大型产品,也没有完整的主导经历过一个大型产品的生命周期。但是团队其他人都没什么大型架构经验,樊就成了这方面的权威了。大家一看他的架构确实好,而且确实代表未来,就决定用了。但那时候,樊做的架构其实质是一个3000多行代码的DEMO原形演示。而一个真正产品需要的接受过各种复杂企业需求考验的大型架构,樊还没有经验。
而且当时大家已经封闭了,很多人都聚在一起天天设计业务和表结构了。而且,1999年的JAVA,大家都知道,从JAVA本身到开发工具本身都还不是太利索,如果2001年开发,情况就会好很多。但就是各种阴差阳错,NC就上路了。
我想,直到现在,王文京也对NC很是戚戚然。虽然,中间件成熟了,JAVA成熟了,开发工具成熟了,设计模式成熟了,大型软件工程成熟了,但NC架构已经定型了,只能这么继续走了。NC在用友内部很多年都被称为就会花钱不会赚钱的鸡肋,老遭U8事业部的人看不起,因为用友大部分收入还是U8支撑的。但NC不断艰难坚持,也变的越来越好了,唉,起了个大早,赶了个晚集。邵凯经过这么一遭,也深深反省自己在软件工程管理上的问题,于是他接手了用友软件工程公司,这个公司专门做外包,是非常讲究软件工程的。邵凯就是希望能取取经,看看人家外国人是怎么管理的。当然,现在管理软件公司做外包,没有一个成气候的,用友也把外包公司脱离了用友软件,以防影响上市报表成色。
经过NC这一遭,王文京知道这个U9的研发就要沉住气,不能再走NC老路了。
注重架构、注重软件工程管理的U9,没想到这一走就是4年(其实是5年,2003年就有策划,但实质进展在2004年)。
过去的U8架构,是田荣举做的。这个管理软件行业的传奇人物,出自金算盘。然后用友,然后金蝶,然后又回金算盘,然后又回金蝶,然后又回重庆不知所踪。田荣举几乎给U8、K3都带来了至少影响10年的架构思想。现在,做管理软件的,搭建架构,都是借鉴的是田荣举的思想。而田荣举在10年前就这么思考了。可见是高人。
而U9呢,谁来负责?黄涛浮出水面。黄涛,也是出自金算盘(这个公司到底怎么了?黄埔军校?)。然后在用友就没走。在郑雨林、章培林、杨祉雄、高少义、向奇汉、何经华、黄义璋这些猛人辈出的用友,黄涛并不引入注目。直到U9,才慢慢出现在媒体坊间。
黄涛这次是真沉住了气。经历了这么长的中国管理软件发展,黄涛知道管理软件研发的每一个核心点。管理软件,首先是管理。没有一整套完整的先进的管理体系(而不是功能),管理软件只能成为电子化工具,成为跟随客户需求的一个工具,而无法帮助企业提升管理。
所以,黄涛一开始就大力招聘业务专家。他实行交叉管理模式。按职能分:架构平台组、开发管理组、业务功能设计组、数据库设计组、测试组、文档组、UI组。按系统又交叉分为:财务、生产、OA、HR等等。真正按照流水线生产方式来生产。
而在架构上呢?黄涛的设计又比田荣举10年前的设计高出哪些呢?
我也不是用友人,所以我也拿不到更详细的材料(这是管理软件行当的一个浅规则,管理软件厂商很少在网站上详细介绍产品,如果你真是企业,想用他们的产品,可以电话咨询,销售人员会跟进递送资料)。
从我手上的这份U9宣传手册来看,U9的架构并没有多大改进。
U8架构的时代,还没有面向组件。所以无法二次开发。而K3赶上了COM时代,所以可以有二次开发调用COM接口。而现在面向组件已经走进了面向服务时代。COM/COM+已经由于是WIN32时代,.NET时代屏蔽了COM,而且COM也无法穿透防火墙,现在都互联网普及了,上下游需要整合了,必须穿透内部防火墙走向外部EAI。所以,开发WebService业务组件是必须的。和U8比,当然比U8强很多,U8连面向组件都没有赶上,而U9直接跳过面向组件,走向面向服务。所以,U9一直号称自己是第一款原生SOA管理软件。
SOA是个基础技术。重要的是看U9架构。
其实,作为管理软件的架构,其实是比较简单的技术。大致相同。所以从金蝶EAS,到U9,到SAP Netwear,都差不多思路。管理软件最主要的成功门槛还是管理思想、项目质量、项目进度、项目文档、项目大规模团队组织协调、咨询渗透、专业培训。管理软件最主要的技术门槛还是在于海量数据存取,但性能受业务需求、功能设计、数据库设计、代码开发多种因素影响,所以需要在各个层面去调节。我过去做架构师的时候,由于数据库产品有些BUG补丁没有出来,由于OS有些BUG,由于COM+有些BUG,还有开发工具对于COM+和ADO支持上有些BUG,所以被性能弄的很是麻烦,整天在客户机房蹲守检测CPU、内存、I/O、线程、池化、连接数、事务并发。
我也是做管理软件架构的,所以在这里给大家讲讲一个管理软件的一般架构思想。
一个架构的作用:
1业务程序员少写代码就能实现业务功能
2有了需求来,也好定制修改
3也稳定
4性能也高
5部署和支持也方便
6安全性也高
为了实现这些目标,所以我们需要具备以下这些组件设施:
1登陆用户口令验证、license许可验证、盗版验证、过期失效验证、版本差异验证
2主控台 用户功能树 管理主控台
3表单设计器、业务实体设计器、工作流设计器、报表设计器、功能菜单设计器、多语言设计器、多皮肤设计器、查询过滤定制器
4UI框架:Grid/Toob bar/Tree/TabSheet/Menubar/参照录入组件/Edit/Button/Combo之类
5单实体输入框架、主从List/Detail输入框架
6运行配置参数设置、单号计数器、业务预警设置
7异常框架、业务实体权限框架、业务实体存储引擎、业务实体查询引擎
8报表:套打、单据报表、普通二维查询统计报表、交叉报表、图表
9工作流引擎、消息引擎、自动任务引擎
10企业组织结构设计工具、权限分配工具、数据导入导出工具、数据备份恢复工具、升级更新工具、错误诊断跟踪工具、性能监测工具、日志查看工具
11OFFICE集成、BO集成、通信集成、邮件集成、短信集成、IM集成、搜索集成、电子商务集成、企业门户集成等等一切外围集成
有了这些基础,就可以在其上开发业务模块了。一般,让业务开发人员能够顺利开发业务组件并且能顺利插入这个平台去运行,还需要有Example、Docs、IDE。这样,在IDE中,自
动就能查到所能调用的公共业务类库命名空间的成员,也能有帮助文档知道如何使用,更有Example代码,几乎修改一下就能用。于是,几乎,业务人员不需要直接使用VS之类的开发工具。如果确实做不了,平台组会扩充平台功能。如果平台也不很好的完成,就需要平台组来分解需求抽象需求仅提供公共功能API,然后让业务人员调用API,适当使用VS工具,但都容易很多,开发的速度、质量稳定、性能都不错。
没有平台,高手低手都混在一起,开发的功能模块有的强有的弱,有的很好扩展很好修改原代码也很好理解性能也不错质量也不错,有的代码一团浆糊BUG百出几乎无法下手修改,整体质量无法保证。有了平台,就让能力高的开发平台,让能力低的去使用平台。毕竟,我们能招到的高手不多,而且成本高,大部分都是资质平凡的一般程序员。如果整体成功,就需要搭配各施其职。
我看这次U9引入了DSL这个新技术。这也是我10多年一直摸索的,但却没有成果的。如今,Google和Ruby给了我很多思路。Google的REST、JSON、JAVASCRIPT,能够实现比BEPL广泛的Mashup,也比JAVA要轻量级。而Ruby更是引入真正的DSL脚本,像在编写游戏脚本一样。如果我们没有DSL,我们必须用JAVA这类原生重型语言操刀,这就难为业务开发人员了。
我们并不期望DSL给客户的IT维护人员用,但至少也不希望业务开发人员去全面深入的学习JAVA或C#,大家都知道现在各种框架越来越大,各种类库越来越大。让一个资质平凡的程序员去学习这些东西还要能开发,那上手需要多慢,培训成本需要多高。
但是,从U9在媒体透露出来的各种消息来看,U9现在已经完成的业务模块比较少,应该是财务、供应链、OA、HR这四部分(有没有生产管理、质量管理、CRM、物流仓储?没看到宣传内容)。其实要做ERP,就必须从CAD设计到产品数据管理到物料清单、采购、供应链、生产排程、仓储管理、生产成本管理、质量管理、物流、销售管理、市场管理、服务管理、客户管理、商业智能、企业OA、人力资源都得需要(不熟悉ERP构成的可以学习这些完整的ERP链,SAP基本业务套件[行业解决方案除外]也不外乎这些)。
四年,听说用友每年投资1个亿研发,U9研发甚至动用了600-800研发人员,堪称国内第一单产品动用人数最多的完成这么点,而且从看到的资料,UI和功能细节上都不能让人信服这是一个研发了四年的产品。我个人猜想,估计还是NC的两个错误:1 技术的不成熟,从.NET/WPF/WCF/WF,想实现的架构底层技术不支撑 2软件工程管理的不成熟。
其实还有第三点:管理思想和业务细节。
黄涛过去一直做技术方面,这次统领产品大局,研发时间之久却业务模块出的少,很有可能和我估计的第三个软肋有关(用友一直封锁消息做的很好,具体我不清楚,我只作为门外汉猜测而已)。
U9不断跳票,从王文京说的2006,跳到2007,然后是2007年底,然后是2008年3月。希望U9在今年上半年能够正式发版。
而金蝶呢,K3老去,EAS产品技术成熟却无法决战未来10年。因为从最近发布的.NET 3.5来看,.NET在架构思想上比JAVA走的要先进的多。而JAVA,在众多厂商的博弈中背负了大量的包袱无法快行。
U9是又起早了呢,还是正好。不管怎样,管理软件行当都想看到未来的标杆是什么样?
发表于 2014-12-2 09:56:38 | 显示全部楼层
我也想写一篇的,我用了3年多了!没空写!
回复 点赞 拍砖

使用道具 举报

发表于 2014-4-28 22:29:53 | 显示全部楼层
:):):):):):):):):):):):):):):):)
回复 点赞 拍砖

使用道具 举报

发表于 2014-4-24 20:16:22 | 显示全部楼层
感觉u9很强大,很好,正在使用
回复 点赞 拍砖

使用道具 举报

发表于 2014-12-2 09:14:12 | 显示全部楼层
学习了,,感觉U9还是强大的
回复 点赞 拍砖

使用道具 举报

发表于 2014-3-16 08:28:34 | 显示全部楼层
有道理,现在改进了很多。
回复 点赞 拍砖

使用道具 举报

发表于 2009-6-20 23:00:56 | 显示全部楼层
希望如此吧。
发表于 2009-6-21 12:16:51 | 显示全部楼层
呵呵.,.U9啊.不错
发表于 2009-7-28 18:02:09 | 显示全部楼层
见解很独特。。。。。。。。。
发表于 2009-8-28 08:47:17 | 显示全部楼层
到底是如何,现在还是个未知数
发表于 2009-8-28 09:55:38 | 显示全部楼层
还没机会接触到
发表于 2009-8-28 10:08:48 | 显示全部楼层
貌似很强的样子阿
发表于 2009-11-8 19:02:18 | 显示全部楼层
好,就是好!!
发表于 2010-5-6 16:57:07 | 显示全部楼层
楼主真有才
发表于 2010-7-15 15:30:08 | 显示全部楼层
U9加油!!!
发表于 2010-7-15 22:13:04 | 显示全部楼层
都是飘无虚渺,呵呵呵
NC用了10年成了今天这个局面!

u9他就是再快也需要5年吧,呵呵短期内是看不出任何效果的。
这个市场竞争已经到了白热化阶段了。
发表于 2010-7-17 07:46:34 | 显示全部楼层
貌似很强的样子
发表于 2010-7-21 11:22:54 | 显示全部楼层
任何产品都要经过市场的检验才能决定它是好是坏。
发表于 2010-7-22 06:54:28 | 显示全部楼层
U9啊,我希望是标杆!
发表于 2010-7-22 11:46:58 | 显示全部楼层
细节功能还是不行,缺乏项目检验,或许五年后会走向成熟
您需要登录后才可以回帖 登录 | 注册账号

本版积分规则

QQ|站长微信|Archiver|手机版|小黑屋|用友之家 ( 蜀ICP备07505338号|51072502110008 )

GMT+8, 2024-11-27 15:48 , Processed in 0.064356 second(s), 13 queries , Gzip On, Redis On.

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表