文档章节

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

猪刚烈
 猪刚烈
发布于 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
关于ETL工具的思考

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

技术小美
2017/11/19
0
0
华中电网项目日志:再梳理一下SG186概念

梳理一下SG186概念的问题。目的是做服务就得揣摩服务目标和目标程度,所谓知己知彼吗。那么什么是电力“186”工程呢?这个工程与电力的信息化有什么关系呢?与那些为电力行业服务的IT厂商有什...

晨曦之光
2012/03/09
0
0
【智能工厂】— 五大核心系统介绍

前言 小编最近在做MES系统,MES(Manufacturing Execution System)制造执行系统,工业4.0时代已经到来,智能制造、智能工厂的打造是国内生产制造企业势在必得的项目。 正文 为什么会有智能工厂...

zt15732625878
04/01
0
0
华中电网项目日志:业务与项目背景

最近需要和电力系统的客户打交道,需要长期驻入电网项目组。时间很紧,12月份的数据规划与业务建模必须通过国家电网的验收。本文旨在记录我对这个项目的业务与技术记录,以与同事进行沟通。 ...

晨曦之光
2012/03/09
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

OSChina 周三乱弹 —— 我居然在 osc 里追剧

Osc乱弹歌单(2018)请戳(这里) 【今日歌曲】 @舆情风控小组 :分享王菲的单曲《笑忘书》 《笑忘书》- 王菲 手机党少年们想听歌,请使劲儿戳(这里) @艾尔库鲁斯:如果给大家一个选择的机...

小小编辑
36分钟前
45
4
rabbitMq的客户端使用笔记

1、channel声明队列的queueDeclare方法的参数解析 durable: 是否持久化, 队列的声明默认是存放到内存中的,如果rabbitmq重启会丢失,如果想重启之后还存在就要使队列持久化,保存到Erlang自...

DemonsI
44分钟前
0
0
“全新” 编程语言 Julia开箱体验

本文共 851字,阅读大约需要 3分钟 ! 概 述 Julia 是一个 “全新”的高性能动态编程语言,前两天迎来了其 1.0 正式版的重大更新。Julia集 Python、C、R、Ruby 之所长,感觉就像一种脚本语言...

CodeSheep
今天
11
0
软件自动化测试初学者忠告

题外话 测试入门 很多受过高等教育的大学生经常问要不要去报测试培训班来入门测试。 答案是否。 高等教育的合格毕业生要具备自学能力,如果你不具备自学能力,要好好地反省一下,为什么自己受...

python测试开发人工智能安全
今天
5
0
java并发备忘

不安全的“先检查后执行”,代码形式如下: if(条件满足){ //这里容易出现线程安全问题//doSomething}else{//doOther} 读取-修改-写入 原子操作:使用CAS技术,即首先从V中读取...

Funcy1122
今天
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部