集成类项目的几个内容。通常我们在项目中可以达到第三步。 之后的工作实施难度会比较大,真正做到完整的企业服务识别的案例很少,没见过。
编号 | 工作内容 | 描述 |
1 | 应用接口集成 | 包括接口数据标准化,使用集成平台来互联应用系统 |
2 | 公共数据服务 | 确定数据的主从关系,集中分散的数据,关联分散的数据 |
3 | 公共功能服务 | 提取公共的功能做成服务 |
4 | 应用系统服务化 | 应用系统内部功能分解,实现为服务,达到业务功能复用的目的 |
5 | 基于服务构建流程 | 基于已有的服务构建新的流程和应用系统 |
第二部分工作公共数据服务化比较可行的,而且很有用。对跨系统的公共数据做管理,提供访问数据的服务接口。主数据管理可以覆盖这部分工作的内容。 这里按自己的思路,对数据服务的内容和模式做描述。
可供管理的跨系统的数据有几个类别,元数据,数据字典,主数据,交易数据(业务操作数据)。不同类别数据的管理应用程序有一些小差别,但基本功能相似。
1. 数据和数据结构关系的存储。
2. 数据基本的增删改查。
3. 非实时批量数据导入,使用ETL技术。
4. 运行时数据的接入。使用EAI, 消息中间件技术。
5. 数据同步。保证主从多个数据副本的一致性。
6. 数据访问接口,即数据服务接口。
7. 多种数据分发策略。主动推数据方式,拉数据方式,一对多的发布订阅方式。
8. 数据版本管理。不同版本数据的映射关系和转换。
9. 使用上下文管理。给特定的应用范围和场景定义所需要的数据版本和数据范围(通常是所有数据的一个子集)。
才参加的项目上接触过几类数据管理产品,觉得挺有代表意义。
1. 医疗术语编码服务产品,Common Terminology Service。 医疗行业数据比较复杂,标准化程度高, 有很多医疗术语编码标准包括疾病编码,药品编码等等。医院的多个应用系统都保存术语编码,同类别的术语编码存在多份,版本和内容存在不一致性。构建术语编码系统在整个企业范围内提供唯一的标准的术语编码数据服务,保证术语的正确性和唯一性。这属于数据字典类的数据管理。管理模式特点为:现状是一份完整数据在多个节点存在,改为单一存储,整个医院范围只保存一份,作为标准为其他应用提供数据访问服务。
2. 企业人员主索引产品, Enterprise Master Person Index 。 医院系统内保存患者基本信息包含作为唯一标识的就诊号,患者在多个医院会有多个就诊号。EMPI产品提供同一患者在不同医院之间患者基本信息和就诊号的关联。 用于在更大的范围内为患者提供医疗服务。这属于主数据类的数据管理。管理模式特点为:现状是不同的局部范围内有完整的数据, 需要对这些数据进行集中的关联。
3. 医疗临床数据存储产品,Clinical Data Service。 把医院不同医疗业务系统的数据做集中存储, 实现一个患者所有临床数据的统一视图。这属于交易数据类的数据管理。管理模式为:现状是不完整的数据分散存储在多个节点上, 改为集中存储并关联局部的数据。
数据管理产品 | 数据类别 | 管理方式特点 |
CTS | 数据字典 | 完整的数据, 分布存储多份à存储一份标准的数据 |
EMPI | 主数据 | 完整的数据,分布在不同系统à集中对数据进行关联 |
CDR | 交易数据(业务操作类数据) | 不完整的数据,分布在不同系统à 集中存储,把分散的数据进行关联形成统一视图 |
这里不对所有的数据管理产品和管理方式做总结,只是抛砖引玉。 推荐不拘泥于一些数据管理的标准模式。综合考虑性能,存储成本,现有系统改造成本,进行数据管理的设计。我们的目标是明确的,在全局范围内保证数据的正确性,完整性,一致性。
对于一些类别的数据有成型的数据管理产品, 建议直接使用产品。 自己开发数据管理系统,通常会把访问接口做到企业集成平台或者服务总线上,实现数据即服务。
个人认为目前做企业的集成类,SOA类项目,除了应用接口集成,数据管理服务就是最重要的部分了,可行而且很有用。 比功能服务化要可行和靠谱。