关于某企业系统集成的一些初步思考

关于技术路线：

　　新系统的集成注定不会是将所有应用的前端移植到Flex平台那样简单，这对客户的吸引力非常有限，同时也决定了客户的投入。我认为我们提出的整合方案在强调基于Flex的富客户端技术为客户提供的良好用户体验的同时，应该把重点放在系统整合后给客户带来的“1+1>2”的聚合效应上，这是系统整合的主要价值所在，也是吸引客户追加投入的主要动力。目前我们能直接预见的具有聚合效应的“整合点”有：统一的身份认证和权限管理（包括单点登入）、统一的业务流程制定和监控，还有更多深层业务上的整合需要我们结合客户的实际需求进行挖掘，特别是那些过去需要跨越多个部门和多个应用才能完成的繁琐工作，在系统整合之后将会变得简单而快捷。从技术的角度看，这一切都意味着过去独立的子系统在整合后必须对外开放，保证各子系统之间能够实现互操作,很显然这需要分布式技术的支撑.同时我们可能需要在架构中引入一种平台或媒介负责协调各子系统间的通信和统一的安全机制（这与SOA中的ESB非常相似）。总之，目前看来我们的解决方案必然会涉及SOA和云计算特别是私有云方面的技术。就私有云方面我认为我们可能更多的是借鉴一些思想和理念来包装我们的解决方案，作为重要的特性向客户宣讲，毕竟目前云计算并没实质的技术标准和规范，而在实际采用的技术上，我们可能会更依重SOA的相关技术。（就Mashup技术，我会在最后谈一下我的认识。）

项目的实施策略：

　　1.最为稳妥的实施方案应该是分多期推进，分批地将现有应用整合起来，或将它们慢慢地迁移到新架构上来。在项目初期，我们应该优先选择那些客户依赖度高，改造难度低的系统进行整合，这有利于团队逐步积累经验以应对更加复杂的系统，更重要的是有利于建立客户对我们的信任，吸引客户在项目中的持续投入。

　　2.目前可以预见的是，基于java或.net构建的B/S系统比重应该会比较大，且改造起来也会相对容易一些（当然这也取决于系统本身的质量和复杂度）。

　　3.对于那些使用了陈旧技术的老系统，情况就不容乐观了，一方面掌握这类技术的人才已经很少，且相应的文档等资源也可能很难再找到，并且这类系统的源码或原供应商的可能都已不存在了，如果出现这类情况，则需要考虑重写这个系统。对于开发人员，重写总是比修修补补更受欢迎，最大的问题还是在历史数据的迁移上。从公司角度看，改造有改造的报价，重写有重写的报价，如果能以重写的方式扩大合同额，自然是一件好事，问题主要在于客户是否肯为此买单。对于客户来说，重写这类系统也是有一定吸引力的，因为既有的陈旧系统普遍存在用户体验差、与现有业务流程脱节等问题。但是技术团队会有一个底线，这个底线就是：如果没有源代码，或系统使用了过于陈旧的技术以及系统本身因质量问题无法清晰分离前后台时，都应该选择重写系统。在大的策略上，我们应该尽可能地将这类系统的改造放在我们路线图中靠后的位置上。

　　4.我们应该对所有子系统采用的技术平台进行分组，考察同类技术平台下的系统数量从而确定是否会为此类技术平台组建专职团队来改造这类系统。比如在44个既有系统中，如果仅有1-2个delphi应用我们会怎么做和有7-8个delphi应用我又该怎样做应该是有明显差别的。

　　5.如果是重写系统，对于历史数据的处理是需要特别考虑的。这里不外乎基于原有数据库重写应用服务、在原有数据基础上扩展和重新设计数据库并转储历史数据三种方案，对此，我们应该根据每个系统的实际情况，特别是新需求的影响来确定选择何种方案。

项目的挑战与风险：

　　如果真正达到上述的整合目标，我认为这将会是一个规模非常大的项目，持续时间也会相当的长，对于客户 ，我不知道他们是否有同样的预期，以及愿意为这样的预期投入多少。对于技术团队，众多子系统使用了不同的技术平台，整合这些系统需要我们熟悉并掌握所有这些技术平台，这是一项非常艰巨的任务，对于一些过时和淘汰的技术而言，更是“得不偿失”。对于公司，是否会招募某些特定平台的技术人才以及日后对他们的规划也是需要考虑的。

一些技术策略：

　　对于那些在客户端混杂了业务逻辑的C/S系统,若混杂程度不是很高，可以考虑在后台端再铺设一层服务层，将原客户端中的业务逻辑移植到新的服务层。这一策略秉承了OO设计中的开闭原则：系统对扩展开放，对修改关闭。因为任何对既有部分的修改都可能会带来潜在的bug，因而需要重新进行回归测试。但如果只是扩展，则对已有系统的影响非常小，团队可以集中于新增部分的测试，并信任原有实现。我们应该在所有系统的改造中广泛使用这一原则，能通过扩展实现的一定不要去修改已有部分。

关于mashup的补充说明：

　　通过最近两天阅读mashup的有关书籍，我对mashup已经有了一个整体的概念。mashup有一个非常大的背景，那就是互联网开放的生态环境。mashup所依赖的三大数据来源：public API, web service, data feed的共同特征就是开放。所有mashup案例都是将两种以上的开放服务或数据，揉和成新的应用。我觉得将mashup应用于企业应用集成是可行的，特别是如果能依赖过去两个独立系统开放出来的API,复合出过去客户无法统计和得知深度数据，将会给客户带来巨大的增值效益。但是我相信大的前提一定是需要所有系统要先开放，这实际上与SOA的要求是一致的。唯一不同的是SOA倾向于使用统一的机制（ESB）管理所有服务，并作为中介沟通前台与台端服务，而在互联网背景下的mashup是不存在这一问题的。