[转] 我所经历的IBM SOA与系统整合

2006年，一汽大众新上来一位总经理，新加坡人，整个一国际背景高端管理人才，是德国人和中国人博弈后取得的胜利。

一汽大众过去是从总部到区域到终端一体化的大盘管理模式，很僵化很粘稠，不利用快速反应。于是这位新任总经理就开始改革，大权从总部下方到区域，每个区域经理都是一方诸侯，各显神通。

那这就出现了一个问题，各个诸侯都在祖国980万平方公里烽烟折腾，你一个总经理待在总部高高在上怎么管理？

当然，想到的肯定是信息化。让信息化打通全国区域信息，终端信息，这样就在总部一查到底。

但是在要数据的时候，IT部门却汗流浃背，因为真实的情况是，一汽大众这么多年上了很多IT项目，每个部门都有若干个软件在使用，而且有些软件是某年的一个项目，目前已经不再使用了，但IT部门根本不知道。而且每个部门建设的信息系统，都或多或少存在些重复数据，当时做的时候也没想到和其他部门统一标准。而且由于部门隔阂，有些部门之间的数据还无法连通。这样多标准、多口径的数据，是没法给老板汇报的。怎么办？

总经理一生气，找到了IBM，让IBM想辙。IBM给出了这么几招：
1 到底有多少信息系统，这些信息系统的关系是什么，这些信息系统的使用者是谁，他们会产生什么信息，他们管理什么业务？这些东西都需要梳理一番。

2 理清现状，该整合的就整合，该统一的就统一，空白的没有IT支撑的业务该新上就要新上。

3 在这个整合完的新IT模式下，出老板需要的统计数据。

这个项目就是IBM树为典型的SOA项目。因为一汽大众够大，因为IBM正在猛推SOA概念。2006年，于是项目启动了。

IBM第一个要做的就是现状调研、梳理、然后诊断优化、规划。所以这一阶段，是个典型的IT诊断与规划的咨询子合同。（注意，这种模式，我接下来还会反复讲到IBM是什么样的打法）

IBM不梳理则好，一梳理发现了不少问题。
1 一汽大众和4S店的关系是若即若离的，不是强权管理的。所以一汽大众对4S店的IT应用也没什么要求。IT应用层次不齐。而且4S店是独立法人，属于连锁加盟形式，所以也害怕一汽大众看到他真实的经营状态，不愿意把数据上传给一汽大众。

2一汽大众建设的信息系统太多，所以引入的供应商也多。一个4S店，运行了最多达16套软件。而且每个系统都是各个业务总部垂直业务部门领导上的，当然各个系统之间的对接也不太好。

IBM东西南北中调研了够30家区域和4S店，因为每个地域要选择高中低三个层次的4S店，这就是工作量。根据调研，IBM做了一份非常详细的报告（够出一本书的厚度），描述了一汽大众目前的IT现状。从整体应用系统体系结构图，到各个层面各个业务部门各个子系统，到各个子系统的功能模块，流程，都梳理了个遍。现在这个资料被一汽大众IT部门视为财富，因为连他们自己都无法说清楚现在到底有多少IT系统在跑，到底关系是如何，到底功能如何？这个事情IBM好像就花了3个月时间，10多个人的团队全国奔波访谈、收集资料、编写报告，整天飞来飞去，还整天开会熬夜核对。

然后IBM就开始干第二个子合同，领导整合项目。这又是一个IT咨询项目。到底具体怎么整合，这个方案需要IBM出。而且还要IBM负责带领众多软件厂商来落实。

于是，IBM来了一帮项目经理和咨询顾问。项目经理们负责分解目标到可落实的任务，负责计划进度、报告、推动、记录、协调资源。咨询顾问们就按照项目经理安排的任务开始工作。需要一汽大众IT部门人干什么，需要哪些IT合作伙伴干什么，需要一汽大众哪些业务部门哪些人干什么，需要IBM咨询顾问干什么，都一一分解。每个星期五上午报告，一个个的子项目过，看进度是否符合计划。并且还要安排下一周的工作计划、落实到具体人身上。

这个整合咨询项目很具体，所以IBM要求每个IT合作伙伴把他们自己的软件的每个功能的UI字段信息，数据库结构说明、数据来源说明都要给IBM一份。这些咨询顾问就在梳理各个系统之间的数据是否关联、是否重复，是否统一编码规范，他们之间是如何保持同步的。

IBM最终出了一份报告，就是各个子系统需要整改什么，不统一的数据标准需要如何去慢慢替代或映射，以后基础信息如何保持一致化更新。

IBM是让各个业务系统之间连通、统一了。

于是，各个IT合作伙伴就开始修改自己的软件，符合要求。

接下来，IBM得到了第三个合同项目，还是个IT咨询项目。但这个项目也有些IT技术，不单纯是咨询写点方案什么的。这个合同项目就是要把4S店的、区域的数据上传到总部，和总部的SAP软件连接在一起。而且要把数据上传到总部后建设成全国大集中数据中心。

这里就用到了中间件，也用到了SOA技术。本来上一个合同的业务子系统之间整合，IBM就想使用中间件，但发现系统规模小，不可能拖那么重型那么昂贵的一个中间件。所以业务子系统之间整合，IBM没怎么管，能用DLL就用DLL，能用数据库互相访问就用数据库互相访问。

而这次，要和SAP连接，要上传到全国数据中心，就要动用重型的中间件了。你看，IBM又是卖咨询服务，又是卖中间件，又是卖数据库产品，又是卖硬件服务器。钱全赚走了。

因为中间件是运行在总部服务器端，我们只是算其中一个业务系统的配合合作伙伴，对从前台到后台的全部技术了解的并不透彻。不过，毕竟大家天天在一起工作（一汽大众专门为合作伙伴开辟了一层楼，各个项目组都在这里，HP、微软、西门子、SAP、IBM等等都在这里）。他们为各个业务子系统都定义了XML格式的数据标准，但数据传输使用的是消息中间件，有定时设置，有状态检测，有覆盖或新建冲突规则设置，有日志。每个上传的信息都可以单独设置规则。

SOA应该是例如SAP发生了某个业务，需要触发一个消息，然后让远方的4S店的某个业务系统激发消息后再处理。IBM确实也是这么要求SAP和我们各个业务子系统的。不过这个信息不是实时的，而是异步的。SAP激发，但它不会等待4S店处理，它只是把消息和所需数据发到消息中间件就OK了，到底对方客户端是否正确处理了，它不管了。这个消息中间件就不断在调度发送传输着。安全啊、回滚啊，加密，加压啊，挺多技术难度。

就这样忙活，一年就过去了。

第二年，业务系统连通了，该补齐的功能或子系统也都建设实施了，数据也都上传到了数据中心，该重点关注报表了吧。

需要什么报表呢？这又是一个咨询合同了。IBM来调研，各个层面各个部门的调研，总结各个部门需要的报表。

在收集后，IBM开始一张张的报表开始过，看看报表之间的关联关系，看看各个报表的数据来源是什么。对于有些报表要求的数据，根本就没有上传，或者根本就没有这个数据在IT系统中，或上传的内容和当初设计的时候不是一个想法，这就要求给出方案，下步该怎么整改。

一边让业务子系统合作伙伴继续修改系统，该上传的上传，该新增细化功能的就细化。一边IBM在做报表。

但是在做报表的过程中又发现问题了，数据质量不高，历史数据垃圾太多，规范性太少，居然还有错误数据，没法做报表。

于是，又一个咨询项目合同开始了，那就是数据质量提升。
1数据输入规范性校验
2历史异常数据修正或清洗
3数据更新校验
4数据完整性校验
5数据及时性校验

并且还开发了新的子系统，专门用于自动检查这些数据，哪些区域、哪些4S店没有按标准要求来做。还专门安排了总部的岗位，每天监察，每天督促，月底还要通报罚款。闹腾了好长时间。

当然，中间还出过接口设计缺各种状态信息和版本信息的问题，致使排查问题非常难。于是又扩展接口，我们合作伙伴又进行新一轮修改。

好容易数据也上来了，报表也做出来了，数据也清洗好了，以后的数据录入也有强制要求了，这下该万事大吉了吧。

NO，NO，NO。因为报表没有使用BI工具，有些数据是行转列还带计算的。这就性能慢了。再加上数据中心是全国的各个业务子系统的数据，所以增长非常快。所有有些报表需要做报表计算任务才能把报表run出来。这什么意思呢？也就是说，你需要这个报表出统计数据的话，你需要提前1天或3天给数据中心发请求，数据中心就给你开启任务，一个报表计算1-3天可能才能把数据计算出来。可笑吧。加了硬件，加了集群硬件，加了集群中间件，IBM赚海了，。最后没办法，再加一个IT项目。

这个IT项目就是数据归档项目。把一个季度的数据放在一个数据中心。把历年的数据放到其它的数据中心去。这样出周报、月报、季报就快多了。

几番周折，快3年时间，终于告一段落。由于报表格式盯死，而且纯粹SQL跑，存在本质上的性能问题。

一个BI项目终于浮上水面。IBM的智慧地球的一部分：新锐洞察---Cognos。

传奇仍在继续。

在这个案例中，我们总结一下：
1 IBM拿的都是IT咨询单子，吃的是最丰厚的利润，把苦活机械活都给了合作伙伴。而且他们做的是最高层的事情，是获得客户最高层认可的事情。其它合作伙伴干的事虽然很实在，但最高层领导根本看不见也不关注。这是需要我们注意的，我们要转向服务，就要转向这种服务。

2 IBM是怎么源源不断的拿单子的。这个我们需要学习。它是一步步的设坎，一个阶段一个阶段的拿子合同，并不一口气都在一个合同中做完，这样是分阶段的，目标也是阶段小目标，容易实现，风险也小。这种拿子合同的模式我们或许可以借鉴。