一个典型的信息化建设该如何规划？

我们现在正在进行一个贸易公司的整体信息系统建设，从中碰到不少问题，现将规划的考虑如下说明，希望各位朋友多提建议。

背景：
1、一个贸易公司，大约有170人，人人都要上内部系统。
2、现在已经有一套自己开发业务系统，使用.NET 2003，涵盖：询价、报价、订单处理、物流、仓储、财务。这套系统功能丰富，特别是询价报价订单部分，非常有特色，非常适合贸易流程。公司非常依赖该系统，一刻也不能停。
3、公司在全球范围内有10个左右的分公司。
4、数据库以及达到40G的容量，最大的表近2000万行
5、非自动生成的代码量超过60万行

现有问题：
1、现有系统架构不好，代码重复严重，代码质量低下，没有测试用例保障，每开发一个新功能都非常艰苦。但是尽管，公司一刻也离不开这个系统。
2、现有的业务系统已经不能适应公司的发展，公司最近开发了多种新业务，在原先的需求架构上做已经不可能。
3、随着公司的发展，需要越来越多的企业应用，如：HR、财务、固定资产、论坛、KA、等等
4、公司现在的信息部10人，以不能独立开发如此多的项目

对新信息系统价格的总体要求：
1、各信息系统间应统一验证
2、各信息系统间应统一通信，即统一代办任务等
3、要求提速整个信息系统的建设工作
4、要求各系统不能成为信息孤岛，各系统间的数据应方便可以统一获取和分析

设想的解决方案：
1、重新开发我们的业务系统，并使用ROR + J2EE + ORACLE的技术取代现有的.NET + SQL SERVER。主要理由如下：
    a) 旧系统的.NET 2003架构已经不能适应业务发展，与其在上面诚惶诚恐，低效地开发，不如重启炉灶。
    b) .NET可用的资源太少
    c) .NET上不可能使用Front Controller的MVC2架构，除非不用ASP.NET的服务端控件
    d) .NET的事件驱动策略虽然降低了门槛，但是服务端控件和客户端脚本很难配合，使得深入的开发不易
    e) .NET多种开源架构来源于J2EE，如NHIBERNATE, SPRING.NET, monorails等，虽然这些架构也不错，但总感觉说不出
的变扭
    f) 我认为，有2-3个J2EE ROR的资深软件工程师在，转型不会太艰难
    g) .NET的商业控件，生成的HTML太大，大得我们不得不在中国的其他地方托管服务器，使用数据库复制来同步数据
    h) .NET的的ASP控件生成的控件名无法控制，使得页面的自动功能测试很难进行或者维护
2、公司的信息部专注业务系统，充分外包或购买非核心业务来提速整个信息化建设
3、使用CAS来统一验证，CAS支持各种技术的客户端，便于整合
4、开发一个企业应用平台，来负责统一通信，公告等
5、在业务系统中不包含财务系统，购买业界成熟的财务系统。通过业务系统向财务系统的接口来进行凭证的生成、应收应付账款的管理、信用管理
6、购买EHR系统，通过业务系统向EHR系统的接口，来导入业绩数据，来统一计算提成和薪酬
7、建立数据仓库，统一产生各种报表，支持决策

设想的解决方案的问题：
1、CAS只能统一验证，有什么办法可以统一角色？
2、我前面说的企业应用平台有没有开源的项目？
3、在各地建立服务器实在是不得已的，我们这样一个全球化的公司，有没有可能就建立一个服务器，这样可以大大降低维护的成本，和部署的复杂性。
4、业务系统只负责询价、报价、订单、物流、仓储，财务系统和EHR系统分别外包，这样是否有成功案例？会不会影响数据的分析？
5、ROR是否能够扛起业务系统的大旗？我现在对ROR的担心如下：
    a) ActiveRecord不如Hibernate对ORM的支持，领域模型会受到极大的限制
    b) 客户端控件不够强大，例如：是否有向CS系统的多条编辑统一提交的GRID？

非常感谢一直可以读到这里，我也不好意思，一写就罗嗦了这么多。

评论

16 楼 triu 2007-10-26  

解决方案涉及的范围很大，总得来看，技术框架和具体的业务没有冲突，它们可以分开讨论，技术框架是工具，怎么应用就看需求怎么来了。

15 楼 mario 2007-10-25  

感觉更多的是技术层面的讨论，既然是信息化建设应该更多在业务层面的规划，技术只是辅助。
  是先做业务还是先做基础框架
  如果先做基础框架要考虑如统一目录、单点登录、安全管理、运维管理、软硬件平台、甚至包括机房建设、网络建设等等
  如果先做业务系统或模块要考虑做业务先做那些业务后做那些业务
  将上面的建设步骤划分成几个阶段来建设，每个建设的目标是什么？
  如果考虑外包如何将这些系统无缝整合，集成的规范是什么？
  这些问题才是规划应该考虑的，采用哪些技术现在谈起来都为时过早

14 楼 abcx 2007-10-24  

楼主使用了ROR之后，一定要回来跟我们讲讲用ROR的经验教训，这可是一个用ROR开发企业业务系统的活生生的案例。

13 楼 basicbest 2007-10-24  

如果从您所在公司来考虑的话，有几个看法。
1.建议不要选择RoR，在未有类似成功案例的基础上使用RoR风险是巨大的。即使只是部分使用，这样在你自己的系统中就出现了异构的部分。并且，现在使用RoR的公司少，如果采用RoR，会失去谈判空间。
2.建议选用成熟的BPM系统做为基础开发。BPM是趋势，随着竞争加剧以及企业流程的复杂多变，以流程为出发点的BPM更能适应这种环境。
3.角色及权限，可以使用以LDAP为基础的解决方案。
4.我认为可以使用统一的服务器，但是要考虑网络是否稳定。可以考虑浏览器和客户端结合的方式。

12 楼 triu 2007-10-18  

不客气了，都会在应用领域遇到的信息共享方面的问题的，为了解决这些问题，我们也是绞尽脑汁地想办法，希望能一起找出合适的解决之道。

如果需要了解更多的细节，可以直接联系我，QQ：32557647。

11 楼 ron 2007-10-17  

谢谢 triu的笔墨。

很同意：关键还是企业应用平台，否则各个系统不成为信息孤岛都难。

而这个“桥梁”不像直连直通的斜拉桥，更像是连接四面八方的立交桥。这句话说到我心坎里去了。

淬优科技的产品我有机会会研究，但是有一点是肯定的，这必须在我司确认了“.NET向J2EE + ROR”转型之后。

10 楼 triu 2007-10-17  

明白你的意思，这样的方案是可行的，关键还是企业应用平台，否则各个系统不成为信息孤岛都难。

对于你提到的企业应用平台，目前还没有发现有开源项目，我可以提供如下解决方案供你参考：

开发框架是淬优科技在多年应用JAVA和XML技术的基础上发展起来的Web发布框架，由异构系统资源共享Universal Information Integration（UII）、淬优信息总线（UIC）、淬优业务流程管理（UBPM）、淬优技术平台（TriU）四个部分组成。异构系统资源共享类似IBM信息整合解决方案中的WebSphere Information Integrator（WII）。淬优业务流程管理采取了和安码（ULTIMUS）一样的策略，最大限度地提高流程适应业务变化的能力，将流程的控制权下放到了部门。淬优技术平台采用了Cocoon2的思路---用XSLT将XML序列化成HTML或其他格式，以此来帮助分离内容格式、逻辑和对基于XML网站的管理功能。而将UII、UIC、UBPM、TriU集成在一起则是一个比ColdFusion还要快速的开发工具，想想一下不需要写SQL语句和不需要在页面中嵌入代码（JSP在HTML中嵌入JAVA，Cocoon2在XML中嵌入JAVA）了是多方便的开发环境。

异构系统资源共享Universal Information Integration（UII），是类似于IBM信息整合解决方案中的WebSphere Information Integrator（WII）一样的中间件产品，它们都以实现跨数据源的实时查询、存储、缓存；数据的转换、复制、搜索和发布为目的，建起系统间沟通的桥梁，而这个“桥梁”不像直连直通的斜拉桥，更像是连接四面八方的立交桥。
特性：
一，使用UII不需要部署DB2数据库，它使用业界标准来展现数据，自由接入，自由使用。
二，使用方式不同，WII需要提交用SQL编写的查询，用DB2来统一语法，而UII采用将数据库表、字段定义映射成Web Services标记的方式，在操作数据库时，只需要使用统一的Web Services服务，UII自动生成相关的查询并返回用XML封装的结果，不需要编写任何SQL语句。
三，返回结果不同，WII返回符合DB2语法的数据库查询结果集，UII用Web Services返回符合特定行业标准的XML内容。

作为ESB产品，淬优信息总线（UIC）接受包括UII在内的所有Web Services注册，并对其进行管理和提供相应服务。
特性：
一，UIC作为Web Services的提供者，可以相互注册。
二，UIC可以按照服务地域进行拆分、合并。

淬优业务流程管理（UBPM）是自主研发的BPM软件，具有很强的适应企业业务的能力。
特性：
一，采用无需编程的方法，搭配无可匹敌的适应技术，加快流程设计、开发与部署，即使没有完整的流程图定义也可以部署流程，缩短了部署周期。
二，具备“即买即用”(Out of Box)的能力与应变技术，能够适应外在变化，实时调整核心企业流程。
三，在流程的运行过程里，可通过UII/UIC使用和操作其他业务系统的数据，具有强大的整合能力。


任何商务活动的焦点并不仅仅是哪一种技术能达到最好的性能而是哪种技术能令公司在最短的时间之内交付稳固的应用程序。淬优技术平台（TriU）就是这样的Web发布框架，在实现了管理、逻辑、内容、风格分离的基础上，让开发任务可分配给擅长某方面技术的人员，他们不再需要熟悉其它方面，使得开发工作就可同步进行。平台具有高效的可配置性和复杂的缓存机制，配以图形界面的管理控制台，通过配置经过最低限度的Java开发就可以生成复杂的行为，新开发的业务逻辑通过上传软件包而得到支持，只要到控制台对新行为进行相关配置，系统就可以提供新功能了。平台可以使用UII/UIC提供的数据，在控制台指定服务地址和参数即可通过Web Services获得数据库的数据，然后指定数据展现用的样式单文件，框架即可通过特定链接打开用样式单格式化成的Web页面，如此，可以一步一步定义好全部的页面，定义完成时开发工作也就完成了。
特性：
一，TriU可为Web应用提供多样式选择，使用者可以根据自己的喜好来体验应用。
二，TriU为每个使用者提供应用门户，使得使用更方便。
三，由于任务能准确定位，项目集成在控制台通过配置来完成，使得项目管理更轻松，开发周期也大大缩短。
四，再也没有嵌入代码的烦恼了，在数据内容不改变的情况下（一般情况下不会改变），业务逻辑的改变不会引起界面风格的改动，界面风格的变化也不需要修改业务逻辑，这将大大缩短开发周期，降低系统出现BUG的几率，让应用更稳定可靠。
五，用TriU开发并交付的系统将最大限度地贴近客户的需求，客户无需为不必要的子系统、模块付费。

淬优开发框架是集成了异构系统资源共享Universal Information Integration（UII）、淬优信息总线（UIC）、淬优业务流程管理（UBPM）、淬优技术平台（TriU）的综合应用系统框架，它是一套比ColdFusion更有效的开发工具，完整地实现了SOA架构，可帮助软件企业/应用信息中心获的可靠的、快速的软件供应。
特性：
一，淬优技术平台实现了管理、逻辑、内容、风格的分离，使得快速响应成为了现实。
二，使用淬优开发框架来制作软件，不需要撰写SQL语句，只需要配置UII/UIC服务即可。
三，集成的业务流程管理为整合其他业务系统打开了方便之门。
四，革新的技术使得嵌入代码成为了历史。

特点：
· 开发快速：缩短周期、节省人力、降低成本。
· 构件化：提供大量面向高层应用的构件，可任意组合，如同积木一般，在底层基础架构之上构建出不同行业应用产品，提供多样化解决方案。
· 系统运行的健壮性和可靠性：由于业务逻辑的改变不会引起界面风格的改动，界面风格的变化也不需要修改业务逻辑，这将大大缩短开发周期，降低系统出现BUG的几率，让应用更稳定可靠。
· 智能化：可视化操作工具，操作简便，自动处理，减少人为操作错误的可能性。
· 通用性：标准化，支持行业标准和通用接口，通用型强。
· 高扩展性：各构件之间的接口、协作方式都经过良好的设计，并在随着产品的进化而不断的得到优化。
· 适合企业级应用：为客户提供一个统一、简单、基于标准、易于扩充的基础软件平台，客户需要构建应用、整合应用、扩展应用，都可以在这个平台上实行。
· 良好的开放性：跨行业、跨应用和跨平台。
· 良好的集成性：在以构件为基础开发的产品非常容易集成。可以使多个应用程序数据得到共享，提高应用程序的集成性。
· 构件松耦合：平台基于接口的实现，构件之间没有紧密地联系，形成构件间的松耦合，每个构件都能轻松调换，对平台没有任何影响，增强了系统的健壮性和灵活性。

运行环境：
对于运行环境的要求，框架为用户提供了弹性很强的选择范围，包括大多数流行的支持Servlet的Web Server，且不需要部署特定类型的数据库，用户可自由选择系统的运行环境。

9 楼 ron 2007-10-17  

triu 写道

ron 写道

对新信息系统价格的总体要求：
1、各信息系统间应统一验证
2、各信息系统间应统一通信，即统一代办任务等
3、要求提速整个信息系统的建设工作
4、要求各系统不能成为信息孤岛，各系统间的数据应方便可以统一获取和分析

对这样的要求，解决方案肯定不会只有一个，当然，ron认定了ROR除外。

谢谢triu的直言。

我要解释的是，我所设想的方案中，并非用ROR来解决所有的问题。只是用ROR来实现其中的一个业务子系统，至于组成整个信息系统的其他子系统以及应用程序平台都不是用ROR来做的。

用ROR来实现企业应用，难道真的是不可能的事情？

8 楼 triu 2007-10-16  

ron 写道

对新信息系统价格的总体要求：
1、各信息系统间应统一验证
2、各信息系统间应统一通信，即统一代办任务等
3、要求提速整个信息系统的建设工作
4、要求各系统不能成为信息孤岛，各系统间的数据应方便可以统一获取和分析

对这样的要求，解决方案肯定不会只有一个，当然，ron认定了ROR除外。

7 楼 JavaInActoin 2007-10-16  

ron 写道

你的信息量并不大

你好象很轻易就能做出判断

6 楼 ron 2007-10-16  

JavaInActoin 写道

你经常来这个论坛，再去咨询ThoughtWorks，当然觉得这是趋势了，但很少有人意识到的一个事实是:每个人都是井底之蛙，关键是要认识到这一点，你现在认为是当然的事情，放在另一个context中，一切都变了，我不和你做细节上的争辩，多角度思考一下吧。

谢谢你的回复。

坦白地说，你的信息量并不大，除了知道你和我都是井底之蛙之外。

5 楼 JavaInActoin 2007-10-16  

你经常来这个论坛，再去咨询ThoughtWorks，当然觉得这是趋势了，但很少有人意识到的一个事实是:每个人都是井底之蛙，关键是要认识到这一点，你现在认为是当然的事情，放在另一个context中，一切都变了，我不和你做细节上的争辩，多角度思考一下吧。

4 楼 ron 2007-10-16  

JavaInActoin 写道

抛开市场因素，这样的一个大项目，它的生命周期会比较长，而且我想它不会是一次性的，很有可能成为第二个、第三个项目的模板，因此你得考虑技术方向会不会面临风险，我知道ROR有123456，就算代表了一种潮流，但目前来说，还是个小玩意，前途未卜，最后能真正成主流的，未必就是R，谁能保证在R上的投资不会打水漂，今天的系统不会变成明天的负担？

其实我觉得我有ROR的设想不是因为它是一种潮流，而是在最近的学习过程中，发现它确实能够解决很多问题，比如：MVC、COC、REST、开发效率高、维护成本低、等等。

至于说道ROR目前是小玩意，我并不这样认为，在我看来ROR明显已经成为一种趋势。

3 楼 JavaInActoin 2007-10-16  

抛开市场因素，这样的一个大项目，它的生命周期会比较长，而且我想它不会是一次性的，很有可能成为第二个、第三个项目的模板，因此你得考虑技术方向会不会面临风险，我知道ROR有123456，就算代表了一种潮流，但目前来说，还是个小玩意，前途未卜，最后能真正成主流的，未必就是R，谁能保证在R上的投资不会打水漂，今天的系统不会变成明天的负担？

2 楼 ron 2007-10-16  

谢谢，javainaction。

我现在的设想和你说的是一样的，以整合为主。我们作为公司IT部门，以业务系统为主。我所谓的业务系统范围并不是太大，包括：询价、报价、订单、物流和仓库。而其他的财务、HR、KA等以外包整合为主。同时使用统一验证通信的方式让所有的系统有所关联。

对于ROR，我经过一段时间的了解，123456觉得它是好东西，但是业界比较认同的看法是它更适合做网站，不适合做企业应用。但是我们和Thoughtworks公司有过接触，其实是Thoughtworks公司强烈推荐我们用ROR来实现。其实我觉得ROR在ORM、2阶段事物提交、不适合针对老数据库开发这些上面有些不方便外，其它的还是都挺不错的。当然事实是很少有人用ROR做企业应用。:(

1 楼 JavaInActoin 2007-10-16  

一个企业的整体信息化解决方案,其水准很大程度上取决于集成,我说的是业务上的集成,你们如果一揽子重新开发,做成一个软件就行了,天然的统一验证,统一角色,没有集成问题,不要在物理上切成几个独立的模块,做成几个软件.
至于技术上的选择,对于这样一个大型的企业应用,ROR三个字你真的能流利地对客户说的出口吗?