信息系统架构

信息系统架构包括了对于应用架构和数据架构。这里不再介绍具体的方法论，而是考虑如何在设计信息系统架构时有效地避免复杂性。在应用系统层面将通过分层和配置的方式来简化应用系统，从而可以获得简单的架构。在数据架构层面将通过分层主数据的思想来考虑我们如何来管理主数据。

 应用架构

来看一个业务应用场景。企业从生产/采购计划开始，到生产/采购管理，以及现场制造的执行。可以将应用系统划分为两种模式，如图6所示：

图6 生产/采购应用系统划分

左：同一个系统，不同的模块；右：根据层次，分为两个系统

乍一看，好像统一的应用系统比较理想。但需要站在业务的角度重新思考：

1）计划和管理的紧急度和执行不同。有些企业的计划是月度或者周间计划，有些是每日的计划。但是生产执行的系统其要求的程度是分钟级别。

2）计算模式不同。生产/采购计划含有大量的批处理，主要利用的是计算处理能力。而生产/物流的执行涉及到大量的信息采集和信号控制，因此需要快速的交互能力。

3）对于不同响应级别的系统，其系统需要的高可用和运维级别差异较大。如生产/物流执行系统需要实时热备，而计划和管理对于一般制造业而言，具备小时级别的恢复能力就可以了。

而这里没有把计划和管理分开基于两个模块的交互信息多，而且其响应级别差异不大，因此将其放在同一系统中。在汽车行业内，计划/管理一般作为MRP系统，而执行一般作为MES系统。

谈完了系统的分层问题，下面再谈谈关于实现和配置的复杂性问题。图7是一个具体的例子，其中类型是应用的类型，实现指具体的系统实现，配置是指对应用系统配置完成具体的业务功能。图中上半部分指对于生产线的信息采集和发送类型的应用，经过多年的发展，形成了一个非常复杂的系统群。这导致了架构复杂，数据重复，管理运维困难，升级困难等问题。

图7 信息采集应用系统

而经过分析，发现这些应用系统的基本功能有许多共同之处，发现系统的类型可以归结为信息收集和发送。通过设定不同设备接口的配置，可以实现配置实现对生产现场的信息采集以及控制。因此简化后的应用系统如图7中的下图所示。造成这种复杂性的原因是系统在建设时缺少统一的规划，尤其是缺少未来系统增多时的灵活扩展的考虑。最终造成了出现了大量的烟囱。

 数据架构

在业务架构进行合理划分以及应用系统进行有效分层后，许多时候就将一些数据应该存在的范围定义下来了。但是企业内部存一些许多系统都会使用到的数据，这些数据称之为主数据。有的解决方案看起来很美，如下图：

图8 主数据的管理和使用

但是，对于许多企业而言，这种做法不见得是最有效的，有时可能就是一个灾难。而且由于涉及到数据的管理流程更多，主数据管理又需要独立的系统，因此有必要考虑一种简单的主数据管理方式。首先考虑HR系统，真的有必要把HR系统的主数据独立于HR的应用系统放在主数据系统中吗？同样对于生产的车型信息放在主数据中管理也带来了较大的复杂性。因为这些系统只提供数据，而且它们的变化速度很慢，外部的系统也不会修改他们的数据。他们只要定期将变化点发送到相关系统即可。因此借助ESB的概念，利用ESB来定期更新其他系统的数据即可，如图9所示。

图9 有效利用整合工具来管理主数据

此外的一种数据，比如对于银行或者汽车企业的顾客信息。由于其来源广，信息的真实性以及信息变化后的更新都有较高的要求，可以借鉴主数据管理的流程。但是需要说明的是，可以将同顾客信息紧密相连的应用进行改造，使得它们变成天然一体的应用系统。对于其他需要用到顾客信息的系统可以利用ESB获取顾客信息以及顾客信息的变化。

《理想的数据架构的研究和实现》给出的层次模型我比较认可，见图10。但对于主数据而言，其实现模型值得商榷。从业务架构、应用架构和数据架构综合考虑才能够确定是否需要集中的MDM。至少，对于许多已经具有许多系统的企业而言，根据业务和应用系统将主数据的管理分散在不同系统中是个明智的选择。当然也不能忘记，有些数据虽然不列为公司层次的主数据。但是它们在应用系统中仍然得到大量的使用，可以借鉴主数据的管理思路来有效地管理它们，实现在应用系统层面的集中管理。从而使得应用系统简单和高效。

图10 理想的数据架构

对于交易型系统而言，尽可能做到数据量最小化，这将使得交易系统的性能优良。此外，也使得运维便利。但是数据架构的这些内容最好最到对于用户透明，通过Portal可以让用户的体验就像在一个系统中一样。