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

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

背景：
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？

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

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

谢谢，javainaction。

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

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

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

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

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

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

谢谢你的回复。

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

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

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

谢谢triu的直言。

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

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