文档章节

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

猪刚烈
 猪刚烈
发布于 2014/10/12 11:47
字数 1991
阅读 11
收藏 0

关于技术路线:

  新系统的集成注定不会是将所有应用的前端移植到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是不存在这一问题的。

本文转载自:http://blog.csdn.net/bluishglc/article/details/6423893

共有 人打赏支持
猪刚烈
粉丝 22
博文 708
码字总数 110
作品 1
海淀
程序员
私信 提问
如何让新员工快速成长

1概述 对于企业而言新员工是公司新鲜的血液,如何使新员工能够尽快熟悉和适应公司文化、制度,了解岗位情况,快速地胜任新的工作,以满足公司发展需要一直是企业领导的一块心病。 本文是笔者...

数通畅联
2016/10/28
24
0
关于销售手册和培训工作的关联和启动

@ginger_jiang @Jeasun ,两位的周报中好像都还没有非常完整的关于这项工作的关联思考和当前作用力判断,我们其实非常需要这个工作的推进,具体的工作步骤和计划,我很有兴趣与两位及各位兴趣...

Mishell
2016/06/20
111
5
关于ETL工具的思考

阅读 有感! 通常认为ETL 就是数据抽取, 转换, 加载的过程, 完全正确. 就像数据库就是存储和管理数据的工具一样, 然而数据库并不全部是数据的存储, 最重要的是管理, 即数据的并发性一致性可恢...

技术小美
2017/11/19
0
0
ML梳理02 | 线性回归、逻辑回归

关于线回归、逻辑回归,各位大神总结的很精辟了,下面收藏几个好的讲解,以备忘。 逻辑回归三部曲 机器学习系列(1)_逻辑回归初步 机器学习系列(2)_从初等数学视角解读逻辑回归 机器学习系列(...

RookieDay
02/01
0
0
企业级云若遭受安全攻击,我们第一时间应做哪些紧急措施?

面对云安全挑战,企业必须有效地应对不断变化的环境,确保其业务在未来继续蓬勃发展。当然,网络攻击事故总是难以避免,时刻保持云安全的警惕性也应成为企业战略的重要组成部分。 如何在众多...

你好伤人
03/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

vuex进阶知识点巩固

我们先回忆一下上一篇的代码 computed:{ getName(){ return this.$store.state.name }} 这里假设现在逻辑有变,我们最终期望得到的数据(getName),是基于 this.$store.state.na...

嫣然丫丫丫
13分钟前
1
0
Python出现安全策略问题的解决方法

Python运行期间出现如下错误 import: attempt to perform an operation not allowed by the security policy `PS' @ error/constitute.c/IsCoderAuthorized/408. 解决方法:在脚本的开头添加......

大糊涂
21分钟前
1
0
Angularjs实现控制器之间通信方式示例

利用angularjs开发项目中,控制器之间的通信,比如参数的传递,数据的传递,都是比较常见的。控制器之间的通信,显得尤为重要。常见的方式有如下两种:一、angular服务的方式;二、基于事件广...

前端攻城老湿
28分钟前
1
0
xshell使用xftp传输文件

12月11日任务 15.4 xshell使用xftp传输文件 15.5 使用pure-ftpd搭建ftp服务 1.xshell使用xftp传输文件 示例一:xshell使用sftp传输文件 新建一个会话 定义为sftp 连接登入 可以get文件,下载...

hhpuppy
30分钟前
2
0
深入解析Vuex实战总结

这篇文章主要介绍了Vuex的初探与实战小结,写的十分的全面细致,具有一定的参考价值,对此有需要的朋友可以参考学习下。如有不足之处,欢迎批评指正。 1.背景 最近在做一个单页面的管理后台项...

前端攻城小牛
31分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部