谈企业集成需求(9.16)

标签: SOA架构实施 | 发表时间:2019-09-16 14:21 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
本篇为对近期调研和访谈的企业对ESB总线和集成平台需求的一个初步整理。实际上对于ESB服务总线究竟解决了企业哪些问题,我在前面很多文章都有过系统性的专门描述,因此这篇为零散需求记录。

在跨系统交互和集成上,企业最大的问题是数据问题,即数据不一致和数据延迟导致的跨系统业务协同上出现问题。因此大部分企业会思考对基础数据进行统一管理并提供统一能力,即我们常说的主数据管理,主数据管理可以明确的解决业务系统和问题,也容易和业务部门和业务人员沟通为何要上MDM,而对于MDM实施本身涉及到集成,即还需要同时进行接口服务的统一管理。当前还是大部分企业会思考对于MDM和ESB统一进行建设,有些企业也会同时对两个需求发一个标进行统一建设。

实际上我们看到

1.主数据平台:本身是可以独立建设,即使没有集成平台也可以单独建主数据
2.集成平台:不仅仅是解决主数据相关接口集成问题,而是解决整个信息化应用系统间接口交互和集成

主数据平台的建设,难点不在于系统,而是在于主数据系统的实施,而实施本身的难点本身又在于历史数据的清理和初始化入库。这个本身需要业务部门,包括相关的业务系统高度配合才可能完成。

当前对于企业集成的需求,即使我们使用的是ESB服务总线,但是仍然可以看到集成的需求包括了服务集成和数据集成两个部分,或者把ESB总线当做数据总线来用,或者在集成平台项目中会包括类似ETL的数据集成能力。即大部分的企业集成,在第一阶段仍然是解决数据集成问题,而不是服务集成和应用集成。

数据集成在前面很多文章讲过,数据集成表示数据会在多个业务系统多点落地,这样本身可以降低业务系统之间的耦合性,但是带来的问题是数据会存在不一致性和时延,那么这些问题就必须有很好的管控机制和补偿机制去处理,否则即使系统间集成了照样影响到业务协同。

1. 数据集成:通过接口服务或ETL进行传输传输集成,数据会在多个业务系统落地
2. 服务集成:在业务场景需要协同的情况下,实时调用服务接口进行数据获取,数据不落地

服务集成的实时性最高,当然对业务系统,集成平台本身的可靠性,性能要求也更高,本身接口服务的调用并发量也会指数级增长。因此并不是服务集成就一定比数据集成好,而是应该实际问题实际分析。

当我们采用数据集成的时候,仍然存在两种场景,即定时的进行数据同步,还有一种就是实时的调用接口服务进行数据导入,那么在我们实施的时候更加建议采用第二种折中方式。即既保证了数据同步的实时性,本身又降低了后续业务之间的耦合程度。

在交流的一些企业里面,我们经常也会听到说原来已经实施过ESB总线或类似的集成平台,但是实施效果并不好,而这个实施效果不好注意体现在以下几个方面。

1. 业务价值无法显性化:ESB属于技术平台,导致ESB总线的业务价值很难显性化,IT部门可能认可平台重要性,但是企业业务部门往往对平台并没有直观的认识。而没有业务驱动力的平台建设本身又是难事。

2. 管控治理没有跟上:对于ESB服务总线究竟是简单的买产品还是卖实施在我博客上也讨论过多次,从乙方角度肯定是希望卖产品最简单,但是单纯的卖产品,整个SOA实施方法论,SOA治理管控规范体系无法真正在企业落地。往往是乙方实施商一离场,甲方接口服务又恢复原样,导致仍然出现接口管理混乱的情况。这个原因不是在于ESB总线产品问题,更多的还是实施管控治理方面的问题。

3. 技术平台功能单一:前面已经讲过了企业的集成需求很多,有接口服务实时集成,也有数据集成,文件集成,ETL数据传输,还包括MDM主数据平台的建设。一涉及到集成需求企业往往就认为都是ESB总线能够解决的问题,但是实际上ESB总线很难解决上面所有问题,而是应该一个完整的整体解决方案才能够解决。因此对于这点我们在做SOA项目实施的时候也需要和企业提前沟通清楚。

ESB总线平台的建设,一个方面是选择产品,但是更加重要的还是服务实施,服务管控治理规范流程的建立,而对于这方面经过10多年的大平台和大项目现场实施,我们在这方面也是积累了丰富的现场实施和管控经验,而这些才是确保SOA实施项目能够成功的关键。

 

相关 [企业 需求] 推荐:

谈企业集成需求(9.16)

- - 人月神话的BLOG
本篇为对近期调研和访谈的企业对ESB总线和集成平台需求的一个初步整理. 实际上对于ESB服务总线究竟解决了企业哪些问题,我在前面很多文章都有过系统性的专门描述,因此这篇为零散需求记录. 在跨系统交互和集成上,企业最大的问题是数据问题,即数据不一致和数据延迟导致的跨系统业务协同上出现问题. 因此大部分企业会思考对基础数据进行统一管理并提供统一能力,即我们常说的主数据管理,主数据管理可以明确的解决业务系统和问题,也容易和业务部门和业务人员沟通为何要上MDM,而对于MDM实施本身涉及到集成,即还需要同时进行接口服务的统一管理.

戴尔小企业部总裁:部分平板不能满足企业需求

- Jerry - cnBeta.COM
据国外媒体报道,戴尔全球消费者和小企业产品部门总裁史蒂夫・菲利斯(Steve Felice)在接受媒体采访时表示,市场上的部分平板电脑不能满足企业的需求. 在谈到戴尔的平板电脑销售目标时,菲利斯表示,“我们没有制订具体的销售目标,但我们希望在平板电脑市场上占领足够高的市场份额. 我们是一家思想开放的科技公司,将采用微软和Google的技术,未来数年我们将推出多款采用微软和Google软件的平板电脑.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.

需求分析中的产品定位

- Jessica - 所有文章 - UCD大社区
看过《定位》最大的感受就是产品在诞生之前就决定了他是否能存活或成功. 就像走在商场中,面对玲琅满目的产品,你似乎很难找到一两款绝对同质化的大品牌:. 各式的服装,NIKE的衣服是运动的,但也不会和做户外运动的哥伦比亚冲突. 都是做化妆品,Fancl打出“无添加”没有防腐剂也收获了一群喜爱天然的用户…...