【IT168 管理】
一、 前言
企业应用以信息驱动,并在信息的获取、加工、交换、组合、分析过程中体现自身价值,笼统地讲,上述过程都可以称为“信息管理”。
本文中把“信息管理”简称为“IM”,即Information Management,并不是表示“即时消息(Instant Message)”的含义
对于大型企业而言,IM不仅是实现并不断拓宽上述信息过程领域,还有一个应用深度的问题,而且还是个“水涨船高”的过程。对于信息管理套用一句以前的商业口号就是“人无我有,人有我全,人全我优,人优我廉”,怎么理解呢?
•“人无我有”:别人没有信息化,我做了,获得企业生产率改善、获得了更多的经营效益。
•“人有我全”:别人也作了信息化,我就多做些,不仅是你的OLTP(On-Line Transaction Processing,联机事务处理系统),我还有OLAP(On-Line Analytical Processing,联机分析处理),可以及时发现更多的潜在商业机会。
•“人全我优”:大家的摊子都铺开的差不多,不过我的IM可以更加敏捷地配合业务发展,信息更准确,简言之就是IM对企业业务的服务能力更“到位”。
•“人优我廉”:等到大家都做到“优”之后,我们已经有了标准化的过程,有了大量可重复使用的IT资源,有了技术、业务间顺畅的沟通渠道,同样服务等级,我的IM成本要少得多。
所以,大型企业IM不应该是一堆产品、一堆技术概念、甚至是某些“最新”技术的实验田,本质上应该是业务的支撑能力,或者本身就是企业业务。
二、 信息要渗透到业务的方方面面
抽象的说,要做到“人优我廉”这点包括两个方面——“有相关的信息”和“能够方便的拿到这些信息”,两者缺一不可,而做“优”每一点都很难,更不用说做“廉”。
IM需要的信息既包括企业自身生产的,也包括通过各种渠道获得的。大型企业往往面临一个非常尴尬的局面,到处都信息化了,信息也就散了。以前通过纸质的卷宗,主管看一位员工的资料学历、之前工作经历、健康状态、业务表现、年终评语都有,现在信息化之后,业务表现可能要从销售系统的绩效管理看,而年终评语还要去翻档案柜。所以,为了便于“拿”,首先要把有关的信息汇总起来,保存在“一个泛数据库”里。之所以加了个定语“泛”,在于信息的多样化,即RDBMS、Data Mart、DW、XML、Office……对于很多企业还有各种多媒体信息,如果涉及到物流就还有很多空间信息,此外还有互联网和业务伙伴的信息。之所以强调“一个”是指无论物理还是逻辑上要有一个有效的措施把这些信息汇总,也就是数据要集成在一起,从分散的信息布局向集中的信息布局过渡,否则当信息如洪水的时候IM常常成了“处处灭火”的代名词,在各个信息源之间繁琐而反复地穿针引线,而最终会把IT团队应有的创新能力全部“吃掉”。

图1:信息布局的改变
在具备了汇总能力之后,下面就是怎么样让用户和合作伙伴可以方便地随时随地获取信息,这同样需要集成——集成设备、集成IM通道、集成各种信息检索技术。不仅如此,大型企业的IM还要提供多种面向业务的服务方式。不过在这些之前,有个很关键的问题常常被各种规模IM建设忽略,即信息的有效分类。这个问题看似简单,但它是有效使用信息的基础,有很多现实的问题需要考虑:
•分类是基于业务领域划分,还是作业流程需要划分?
•对跨国企业而言,相同业务领域不同语言的信息如何组织?
•对于Office文档之类的信息,是否必须非此即彼的分配在一个而且唯一的一个分类之中,是否需要跨信息化分?
•是否可以提供基于上下文的划分,例如:“今年的数据”和“去年的数据”这个本身就在变动?
•随着业务的区域化趋势(比如某市->某省->环渤海区域->东北亚…),业务信息出现数据属地和作业地点分离的情况,IM如何区分“本埠年销售收入”之类的既有上下文又包括跨区域信息的情况?
•即便可以划分出一级分类,下面还有二级、三级分类,怎么定义分类层次标准?
至于分类之后的通知和发布,虽然有很多诸如SOA、Push && Pull、复制、快照等数据技术,但还是有太多空间需要填补,笔者再次就不展开了。无论如何,渗透到业务是IM必须、始终致力于进行的工作,否则IT不仅不是翅膀,反而会成为业务变革的绊脚石。
三、 运行维护的保障
如果从运维角度看IM建设,可以划分为如下几个层次:
•仅完成业务操作功能的,没有专门的监控环境建设。
•部署了技术领域运行监控的。
•提供了整体技术平台的集中式运行监控的。
•提供了基于业务影响程度分析的运行体系。
•确保IM自身持续可用基础上,IM自身作为业务优化和改进的环节,而不仅仅是作为业务之外的一个独立机制。
作为大型企业应用,起码要做到第三个层次,否则IM本身怎么做到令用户放心使用的程度?虽然现阶段主要的数据厂商都在向信息管理和内容管理过渡,并且在自己的产品线都提供了技术运维部分相对很全面的机制和产品,但如何切合业务领域,也就是如何从第三个台阶迈上第四个台阶,基本上都只停留在概念阶段。
倒是一些专门的运维产品在积极倡导相关概念并发布了一些不错的产品。作为大型企业应用的规划者,应用建设及配套的运维机制是否有严格的先后次序呢?笔者认为不仅不该分先后,而且必须同时进行(可用性要求非常高的项目,甚至要运维先行)。

图2:应用设计、开发(黑色)与运维设计、实施(灰色)的关系
运维的目的虽然可以列举很多,但最重要的就是保证图1中那个逻辑的“泛”数据库总是可用。不过运维怎么知道IM是否真的健康呢?如果IM自己针插不进、水泼不进,恐怕也只能自己管自己了。但大型企业应用涉及的内容很多,依赖每个逻辑组成自治化的管理很容易造成运维失控的局面。
因此,设计大型IM的时候就要为运维留出通道,而且要把应用自身和数据源产品分工衔接好:应用要尽量提供业务能力的运维信息、数据源产品要提供详细的技术分析报告,最后通过“配置管理 + 业务影响分析建模”等手段,把两者有效地关联起来。目标如下:
“IM技术层面出了问题,除了IT可以知道外,可以换算为业务影响分析报告,通知业务部门和高层;IM业务层面感觉到了不适,除了可以及时通知上下游部门外,还可以由运维机制解析出技术层问题,通知到IT。”
不过考虑到企业IT队伍人员技术背景的关系,很难单纯依靠企业自己的IT实现上述目标,信息和内容管理产品厂商要把现有的运维支持提升,提供配置管理和尽可能方便的“业务影响分析”建模工具。
四、 安全性考虑
信息安全在今天的语境下已经异常丰富了,相信不同时间问同100个人估计能有300个不同的理解和解释。原因很简单,安全的概念本身就很广泛(ISC^2仅CBK就划分了10个),加之IM的应用领域、应用模式、服务对象千差万别。大型企业应用其实更需要安全保护,设计目标里总是信誓旦旦,但实施后评估的时候发现好像都“缩水”了,为什么?原因带该有如下几点:
•大型企业内部坛坛罐罐太多,IM的新成员又总是要和老成员搭线,为了互联而“削足适履”常常是很无奈的选择。
•用户的应用模式变了或者用户觉得麻烦,并且有很有力的业务原因告诉IT:“这个我不能接受”。
•诸如“数据库我要基于证书访问,应用也是、Web访问也是… 但是PKI用哪个?怎么认证?”之类的技术复杂度,把IM的实施人员挡住了。
•诸如“我们的主要业务在浙江、福建,数据中心也在那边,不过上次台风之后IM差点成了没有I的空M了”之类的物理安全因素。
除此而外,还有非常令人头疼的安全策略、安全管理、IM客户端管理,还有大环境下法律法规的要求……
其实逐条分析,为了适应法律、法规,为了让用户“透明”地接受安全性保护,还是有很多技术措施可以做到的,关键在于IM建设中能否方便的用起来。虽然几大厂商在自身的平台上都有相对完善的安全方案,但是大型企业应用很难保证全部都“捆”在一艘船上,可以考虑下述手段:
•采用业内最主流(支持产品多)、标准化程度最高的技术方案,不要做产品厂商的“小白鼠”。
•把安全性作为机制也作为独立的IM组成系统,与运维、应用建设齐头并进,必要的时候还要先行。

图3:为保证IM安全,设计企业集中的安全机制
五、 借他山之石
开源、Web API、外部SOA 访问点都是不错的选择,毕竟企业开始自己IM建设的时候,IT人员很难面面俱到。评估自己的弱项、使用专业的服务未尝不是明智之举。借力的目的也很明确,把企业IM用得着的也都想办法划到图1的那个框里,为了给自己增加选择,可能的话同一个领域划上2个,权作双保险。
六、 总结
大型企业IM核心在其业务功能,但投入更多地在“集成”、“互联”、“运维”和“安全”,越是企业关键业务的IM系统,业务功能除另外4项的商值就越小,同时技术实现之外的内容往往更多。