博客园_yunhuasheng's blog

主数据管理和实施

2011-07-21T03:08:00Z

企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据，并且存在于多个异构的应用系统中。本文将针对主数据管理的概念以及主数据管理解决方案的实施等方面跟大家作一个探讨。

主数据和主数据管理的概念

企业主数据可以包括很多方面，除了常见的客户主数据之外，不同行业的客户还可能拥有其他各种类型的主数据，例如：对于电信行业客户而言，电信运营商提供的各种服务可以形成其产品主数据；对于航空业客户而言，航线、航班是其企业主数据的一种。对于某一个企业的不同业务部门，其主数据也不同，例如市场销售部门关心客户信息，产品研发部门关心产品编号、产品分类等产品信息，人事部门关心员工机构，部门层次关系等信息。

数据管理的范畴和主数据管理的概念

图 1. 数据管理的范畴

如图所示，企业数据管理的内容及范畴通常包括交易数据、主数据以及元数据。

交易数据：用于纪录业务事件，如客户的订单，投诉记录，客服申请等，它往往用于描述在某一个时间点上业务系统发生的行为。
主数据：主数据则定义企业核心业务对象，如客户、产品、地址等，与交易流水信息不同，主数据一旦被记录到数据库中，需要经常对其进行维护，从而确保其时效性和准确性；主数据还包括关系数据，用以描述主数据之间的关系，如客户与产品的关系、产品与地域的关系、客户与客户的关系、产品与产品的关系等。
元数据：即关于数据的数据，用以描述数据类型、数据定义、约束、数据关系、数据所处的系统等信息。

主数据管理是指一整套的用于生成和维护企业主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性 ( “ The set of disciplines, technologies, and solutions used to create and maintain consistent, complete, contextual and accurate business data for all stakeholders (users, applications, data warehouses, processes, companies, trading partners, customers, etc.) across and beyond the enterprise ” ) 。主数据管理的典型应用有 Customer Data Integration —客户数据管理和 Product Information Integraiton —产品数据管理。

图 2. 主数据管理的信息流

一般来说，主数据管理系统从 IT 建设的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库 / 决策支持系统以及企业内的各个业务系统发生关系，技术实现上也会涉及到 ETL、EAI、EII 等多个方面，如图 2 所示，一个典型的主数据管理的信息流为：

某个业务系统触发对企业主数据的改动；
主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；
主数据管理系统为决策支持和数据仓库系统提供准确的数据源。

因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实现。

以客户主数据为例，常见的主数据域包括：

Party：参与方。参与方包含的范围是所有与企业发生了或者发生过正式业务关系的任何合法的实体，比如填写了投保单的参与方。 Party 是分类别的，可以是个人、机构和团体。对于 Party 来说，因为开展业务的需要，可能要对他们进行分级、分类，比如 VIP，黑名单等。个人包括个人基本属性、个人名称、职业、性别、教育等自然属性；机构是指在法律上有登记的组织实体，可以分为政府机构、商业机构、非盈利机构等类别；团体可以有多种形态，比如他们可以是家庭、兴趣小组、某个大机构中的一部分，或者通过某种数据分析技术得出的客户细分群体。
Party Role：参与方在业务中扮演的角色。例如，对于保险行业而言，可以有：投保人，被保人，受益人，担保人，报案人，核保人，查勘员，核赔人等。
Relationship：Party 与 Party 之间的关系 , 例如可以是：夫妻关系、父子关系、母女关系、兄弟姐妹关系、总 ( 母 ) 公司分 ( 子 ) 公司关系、企业事业单位隶属、上下级关系等。
Account：帐户是客户使用企业服务的付费实体。
Location：Location 记录的是每个 Party 可能拥有的所有联系地址，地址的类别包括邮寄地址、email 地址、电信联络地址等。
Contract：Party 与企业之间的契约。

主数据有几个鲜明的特点，其中包括：它是准确的、集成的，其次它是跨业务部门的，再有就是它是在各个业务部门被重复使用的。

主数据管理的意义

图 3. 主数据管理的要素

如图 3 所示：集成、共享、数据质量、数据治理是主数据管理的四大要素，主数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据（主数据），集中进行数据的清洗和丰富，并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。

主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改进数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速度。从 IT 建设的角度，主数据管理可以增强 IT 结构的灵活性，构建覆盖整个企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变化。

以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散于 CRM 等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意度下降，市场份额减少。因此，建立客户主数据系统的目的在于：

整合并存储所有业务系统和渠道的客户及潜在客户的信息：一方面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客户统一视图；另一方面，客户主数据管理系统将形成的统一客户信息以广播的形式同步到其他各个系统，从而确保客户信息的一致；
为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；服务于 OCRM 系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的服务；
实现 SOA 的体系结构：建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的服务，被各个应用系统调用。

主数据管理系统与数据仓库系统的关系

主数据管理系统与数据仓库系统是相辅相成的两个系统，但二者绝不是重复的，也不是互斥的。它们有很多共同之处：

首先二者对企业都具有相同的价值，可以减少数据冗余和不一致性、提升对数据的洞察力，二者都是跨部门的集中式系统；
其次二者都依赖很多相同的技术手段，都会涉及到 ETL 技术、都需要元数据管理、都强调数据质量；
第三就是二者建设手段类似，都需要数据治理的规范作为指导、都需要不同系统、不同部门的协作、需要统一的安全策略。

但是，主数据管理系统和数据仓库 / 决策支持系统二者之间也存在很多不同：

处理类型不同：主数据管理 (MDM) 系统是偏交易型的系统，它为各个业务系统提供联机交易服务，系统的服务对象是呼叫中心、B2C、CRM 等业务系统；而数据仓库是属于分析型的系统，面向的是分析型的应用，是在大量历史交易数据的基础上进行多维分析，系统的使用对象是各层领导和业务分析、市场销售预测人员等；
实时性不同：与传统的数据仓库方案的批量 ETL 方式不同，主数据管理系统在数据初始加载阶段要使用 ETL，但在后续运行中要大量依赖实时整合的方式来进行主数据的集成和同步；
数据量不同：数据仓库存储的是大量的历史数据和各个维度的汇总数据，可能会是海量的，而 MDM 存储的仅仅是客户和产品等信息。

虽然主数据管理系统和数据仓库系统异同共存，但是二者却有着紧密的联系，并且可以互为促进、互为补充。举例而言，数据仓库系统的分析结果可以作为衍生数据输入到 MDM 系统，从而使 MDM 系统能够更好地为操作型 CRM 系统服务。以航空公司为例，客户的主数据模型大致可以分为三部分：

首先包括客户基本信息和偏好信息。

客户基本信息：
- 个人及公司信息
- 消费者市场状况
- 常旅客会员卡号，状态，及累计里程等
- 客户间关系 ( 个体 - 个体，个体 - 公司 )
- 联系地址，包括电话，电子邮件等
客户偏好信息：
- 餐食偏好
- 是否吸烟
- 座位偏好
- 机型偏好
- 公务舱位偏好
- 旅行舱位偏好
- 休息室服务偏好

除了这两部分之外，我们还可以从数据仓库系统中提取相关的信息，作为客户主数据的衍生信息部分，从而更好地、全方位地描述客户特征，这些可以包括：

衍生信息：
- 本月飞行里程
- 年度飞行里程（最近 12 个月内）
- 提前预订倾向
- 习惯预订模式
- 使用自主服务倾向
- 上次预订使用的信用卡号
- 累计 / 本月转签 / 取消航班次数
- 转签航班倾向
- 取消航班倾向
- No Show 倾向等。

主数据管理系统和 ODS 的关系

在某些情况下，主数据管理系统和 ODS 系统可能容易被混淆，的确，从实时上来看，主数据管理系统和 ODS 系统存储的都是实时数据，但是二者存储的数据内容是全然不同的，主数据管理系统中不存储交易数据，比如银行客户的交易流水信息是不应该放在主数据管理系统中进行管理的，这与 MDM 与 ODS 的一个很大区别。举一个航空公司的例子，比如某个客户在电子商务网站上定了一张机票，产生一个订单，然后他又通过呼叫中心要求改签，这个场景中，两个系统之间要实现客户信息和订单信息的共享，其中客户信息共享通过 MDM 系统来实现，而订单信息则需要采用 ODS 或其它手段进行共享，我们是不推荐把此类信息交由 MDM 系统来管理的。

主数据管理解决方案介绍

目前业界比较常见的主数据管理解决方案主要可以分为三类：

第一是依托专业套装软件来实现主数据管理，这类方案是作为套装软件的一部分，主要是为套装软件的其它模块提供服务的，因此，通常功能都缺乏完善性。
还有一类是侧重于分析型应用的主数据管理，这类方案在数据实时同步以及面向交易型应用时通常缺乏整体方案的完整性。
再有一类就是专注于主数据管理的中立的、完整的解决方案，这一类应用独立于套装软件，不仅具有整体架构的完整性和先进性，从功能上讲往往也最为完善，除了具有比较完整的数据模型 (Data Model) 之外，还会提供广泛的集成性，具备先进的机制实现数据同步，并且可以对外提供多种预置的主数据服务被外部交易系统调用，从而使系统具有很强的实时操作性，同时还强调主数据管理、主数据质量控制以及主数据维护的手段和规范性。

企业主数据管理系统逻辑架构

一个完整的主数据管理解决方案的逻辑架构应如下图所示：

图 4. 主数据管理系统逻辑架构

在一个完整的主数据管理解决方案中，除了主数据管理的核心服务组件之外通常还会涉及到企业元数据管理、企业信息集成、ETL、数据分析和数据仓库以及 EAI/ESB 等其他各种技术和服务组件。

其中主数据管理服务又包括如下一些主要的服务组件：

Interface Services：为企业中需要主数据的所有业务系统提供各种服务接口，通过实时的、批量的接口可以读取或者修改主数据，这些接口包括 Batch, Web Services, XML Interface, Messaging Interface, Publish/Subscribe, Import/Export Services, Data Standardization Interface, Directory Integration 等。除了这些标准的技术接口之外 , 对于某些专有系统还提供适配器 (Adapter) 接口 , 通过适配器接口可以和一些特有的系统做接口，例如企业中的传统 (Legacy) 应用系统或者 SAP 等打包应用。
Lifecycle Management Services: 履行针对主数据的 CRUD 操作，执行对主数据存储库中的数据进行更新、存取和管理时的业务逻辑，除此之外，它还负责维护主数据的衍生信息，例如客户之间的关系、客户的偏好、客户在各种客户服务渠道上的行为轨迹等。 Lifecycle Management Services 贯穿整个主数据管理的生命周期，它利用 Data Quality Management Services 来确保数据质量、利用 Master Data Event Management Services 来捕获各种主数据变化等相关的事件，以及利用 Hierarchy and Relationship Management Services 用来维护数据实体之间的关系和层次。
Data Quality Management Services：确保主数据的质量和标准化，这在主数据管理解决方案中一个非常重要的组件，在我们从各个业务系统获取数据之后，要对数据进行清洗和验证，例如对于地址而言，要弥补地址的缺失、地市的缺失、邮编的缺失、进行地址的标准化等。对于其他数据要进行非空检查、外键检查、数据过滤等。然后要对数据进行匹配 / 重复识别、自动进行基于规则的合并 / 去重、交叉验证等，并且还要遵从企业的数据管控规范和流程。它可以是 Master Data Management Services 的一个内部组件，也可以调用整个企业的 Information Integrity Services 来实现。
Authoring Services：依据数据管控流程，定义和扩展企业的主数据模型。
Hierarchy Relationship and Management Services：定义数据实体的层次 (Hierarchy), 分组 (Grouping), 关系 (Relationship), 版本 (Version) 等。
Master Data Event Management Services：捕获事件并且触发相应的操作，包括事件发现、事件管理和通知功能，它在主数据管理系统和业务系统之间进行数据同步时起到至关重要的作用。
Base Services：提供通用服务，包括安全控制、错误处理、交易日志、事件日志等功能。
Master Data Repository:主数据存储库，包括 Metadata, Master Data, History Data, Reference Data 等。

下面我们介绍两个这些逻辑组件之间的协作场景：

图 5. 场景 1-- 初始数据加载

场景 1：初始数据加载：

源数据从外部业务系统及 EDW 系统中通过批处理方式拷贝到磁带；
数据被加载到 Staging DB，进行数据质量分析；
Data Quality Management Services 对数据进行清洗、匹配、标准化等；
ETL Transform and Load services 对合格数据进行转换并准备好加载数据；
Master Data Interface Services 接收批处理更新请求，调用 Lifecycle Management Update Service 进行数据的批量更新；
Lifecycle Management Update Service 调用 Hierarchy & Relationship Management Services 和 Base Services 更新主数据库。

图 6. 场景 2-- 主数据库更新，然后同步到各业务系统

场景2：主数据库更新，然后同步到各业务系统

某业务系统发起一个创建主数据的交易，该业务系统将交易数据以消息的形式发送到消息队列；
MDM Interface Services 捕获该消息，进行消息解析，并调用 Security and Privacy Services 进行权限验证；
MDM Interface Services 调用 Lifecycle Mgmt. Update Service ；
Lifecycle Mgmt. Update Service 再调用 Data Quality Management Services 进行数据的清洗和标准化；
Update Service 调用 Search Services 发现该主数据已经存在，确认这是对已有主数据的更新操作；
Update Service 通过调用外部系统对数据进行扩充；
Update Service 在更新主数据库之前调用 Event Management Services ；
Event Management Services 确认是否需要涉及数据管控方面的处理；
Update Service 调用 Hierarchy & Relationship Management Services 并且更新主数据库；
Audit Logging Services 纪录相应交易日志和历史数据；
MDM Lifecycle Management Service 调用 MDM Interface Services 返回更新处理请求；
源业务系统接收到处理请求之后，利用 MDM 系统发回来的数据对本地的应用系统数据库进行更新操作；
其他所有需要主动被更新的相关的业务系统都会接收到更新后的最新数据。

IBM 主数据管理解决方案

IBM 的主数据管理解决方案 InfoSphere Master Data Management 是 IBM 信息管理大家族的一员。

图 7. IBM InfoSphere MDM Server 产品构成

如上图所示，IBM MDM Server 包含：

Knowledge(知识层)：知识层包括当事方 ( 人员和组织 )、角色、地址位置、当事人属性（统计学信息）、关系、财务简档、多渠道集成、协议和产品、事件等。
Action（交互层）：MDM Server 本身就是按照 SOA 的体系结构设计的，它提供 700 多个开箱既有的服务接口，这些服务可划分为多个主题范围，如下图所示：

图 8. MDM Server Business Services

其中主要包括：
- 当事方人口统计学服务：
- 角色：一个当事方可以扮演一个或多个角色，如帐户方角色服务用于管理当事方在一个或多个帐户中扮演的多个角色，折扣或索赔方角色服务用于维护当事方在一个或多个折扣或索赔中扮演的角色的信息。
- 关系服务：维护当事方对当事方关系，当事方对当事方关系不仅可以存在于两个独立的当事方之间 ( 例如甲方和乙方是配偶 )，也可以存在于双方在某个帐户中扮演的角色范围之内 ( 例如甲方是乙方遗嘱的执行人 ) 。
- 位置服务：维护关于位置的数据，如地址和联系方式。
- 客户服务和销售服务：包含管理多渠道集成所需要的客户服务与销售信息的综合业务服务。例如：隐私服务用于维护数据管理与请求的默认隐私偏好以及客户声明的隐私偏好；偏好服务用于管理复杂的客户服务偏好 ( 比如，特定联系方法和特定产品的联系偏好 ) 。
- 协议和产品服务：帐户或合同服务用于维护某个帐户或合同的详细信息，这里合同定义为一个或多个当事方与公司的合法协议。
- 数据维护服务：MDM Server 提供重复嫌疑管理服务 , 进行当事方记录的合并等。
- 当事方财务简档：比如收入来源信息、财务帐户信息等。
- 当事方识别服务：为每个客户记录创建一个唯一客户 ID，并且维护对其它系统的交叉引用。
- 历史纪录和审核服务：包含检索对象的历史审核数据的服务。
Integrity(完整性层)：完整性服务用于管理数据质量和维护客户数据的单一版本，包括疑似处理、重复处理、数据检查、标准化等。
Intellegence(智能层)：包括事件管理、业务处理规则、数据安全性。
Data Governance(数据管控层)：管理数据实体间的关系 (Relationship), 分组 (Group), 层次 (Hierarchy)，以及数据生命周期等。
Service Inteface(接口层)： MDM Server 支持多个实时和批处理接口，其中实时接口包括 XML 接口、Web Services 接口、消息接口、Java 对象接口、COBOL 和 CICS 接口等。此外，还支持用户自定义接口。

使用 IBM 全套解决方案的主数据管理案例

以下是一个使用全套 IBM 软件解决方案的案例，这是一个典型的客户主数据管理的应用场景，其中使用的产品包括：WebSphere Portal Server，WebSphere MDM Server，WebSphere Enterprise Services Bus, WebSphere QualityStage, DB2 等。

图 9. 主数据管理应用案例

图 9 描述了一个主数据管理应用的端到端流程：

业务系统通过自己的用户界面创建一个新的用户，并且把数据写入了其应用系统数据库中；
该业务系统向 MQ 发送一条 XML 消息；消息中包含了客户基本信息和策略信息；
MDM Server 接收到该 MQ 消息，对此消息进行处理；
MDM Server 通过与 QualityStage 的接口调用 WebSphere QualityStage 的服务，进行客户姓名和联系方式的清洗和标准化；
WebSphere QualityStage 对客户姓名和联系方式的清洗和标准化；
WebSphere QualityStage 返回标准化了的客户数据；
MDM Server 接收到标准化了的客户姓名和地址，查询主数据库获取候选姓名，调用 QualityStage 的疑似匹配服务；
QualityStage 进行疑似处理；
QualityStage 将打分结果返回给 MDM Server，结果表明这是一个新客户；
MDM Server 向某外部系统发出 Web Services 请求，进行数据扩充；
外部系统将结果返回 MDM Server ；
MDM Server 分配一个唯一的 PartyID，并且将客户主数据写入 MDM Server DB ；
根据客户 Profile，MDM Server 发现该客户是新推出的一项新业务的目标客户；
MDM Server 向 MQ 产生一条 XML/JMS 消息；
WebSphere ESB 接收到 XML 消息并且将其转换为市场促销系统所需要的消息格式；
市场促销系统接收到该消息，进行相应的业务处理；
MDM Server 产生 XML 交易响应信息给源业务系统；
源业务系统接收到响应信息，对其应用系统数据库进行更新；
MDM Server 又产生一个关于该新增客户的完整信息，并且发送到 MQ，利用 MQ 的 Pub/Sub 机制将数据通知到各个相关的业务系统；
各个业务系统接收到新增的客户信息，并且更新自身的应用系统数据库。

客户主数据系统实施方法论

客户主数据项目的本质是一个系统间针对客户信息的整合项目，根据以往的经验，大致分成基础实施、双向同步、多渠道访问、全企业采用等 4 个阶段，如下图所示：

图 10. 主数据系统实施步骤

基础实施阶段:

安装 MDM，实现 ECIF 的基础架构
完成主数据建模
MDM 初始数据加载：根据期望的实施方法和策略，将数据从各个业务系统中抽取出来，经过清洗、转换、标准化之后加载到主数据存储库中，在这个阶段主要用到的是 ETL 的相关技术和工具。
使 MDM 的 700 多个业务服务能被其他系统实时连接和使用。

基础实施阶段为客户数据集成搭建了基础框架，为企业提供了转向以客户为中心的能力和价值。后续的阶段主要是在此基础上推动全企业更多的应用和系统来使用这些价值，带来更多的业务增长。所以第一阶段的基础实施对企业来说是至关重要的，也是客户主数据管理项目能否带来业务价值的关键。

双向同步阶段:

通过实时或批处理方式，帮助逐步实现业务系统和 MDM 系统的双向数据更新和同步。这个阶段阶段主要用到的是 EAI/SOA 的相关技术和工具
多渠道访问阶段
整合 WCC 与已有的渠道或新的前台系统，实现多渠道访问。
添加新的客户数据属性和客户为中心的业务流程。

全企业采用阶段:

MDM 成为企业唯一的记录客户信息的来源，促进对客户的洞察力和了解。
促进全企业整合，支持端到端的业务流程。

小结

本文首先系统地介绍了主数据管理的概念，主数据管理系统和数据仓库、ODS（操作型数据存储）之间的区别，并且结合航空公司的需求，给出了航空业客户主数据的简单模型；在理解了主数据管理的基本概念之后，给出了主数据管理解决方案的逻辑框架以及 IBM 的主数据管理解决方案；最后跟大家分享了主数据管理项目实施的路径和方法。

本文链接

最常见的13种主数据管理（MDM）词汇和定义

2011-07-21T03:02:00Z

简单而言，主数据管理（MDM）是公司权衡和重用常见、和准确业务数据的一种全面的方法。然而，它同时也是一种不只有助于组织做表面工夫的快速改进数据管理的策略。MDM系统是为维护公司数据主版本而设计的，它可以通过将其影射到业务规则上来让组织自由处理数据，这种方法比以前的数据管理方法更加的主动。公司之所以关注MDM的其中一个主要的原因是为了从不同的资源和应用上协调功能。

不管你是否考虑实现新的MDM系统还是评估可能的工具和软件来帮助你目前的数据管理和数据整合主动性，了解目前市场的趋势，包括最新的MDM定义和产业词汇都是至关重要的。

为了便于你学习（熟悉）MDM，我们编排了市场上最常见的13种词汇，包括数据管理、产品信息管理（PIM）、企业主索引（EMPI）、MDM集线器等等。

如果没有原数据，那么将不存在MDM，依Forrester's Rob Karel看来。他说道任何激活MDM的，包括定义、业务规则、政策、数据关系和质量优点都是通过使用原数据类维护的。“换言之，原数据是主数据真正值得信任的唯一方式，”他说道。

产品信息管理（PIM）在一个唯一的位置上管理组织的产品数据，因此产品数据是一致的，不管系统或者应用是否需要它。Gartner定义PIM为“通过产品主数据的语义调和来支持不同数据来源的全局产品信息认证、连接和同步软件产品;创建和管理一个关于记录的中央数据系统;（向所有stakeholders）提供单个产品视图;通过监控和校正技术支持数据质量和规范。”

Enterprise master patient index （EMPI），是针对于医疗行业CDI的一种形式。一些医疗组织正在使用EMPI来合并系统之间的病人标识并将这些数据充实到更优分析的数据仓库中。EMPI目录一般包括病人人口统计和病人所使用的器械，并且它们通常能够根据Gillogley Services确定来自其它器械的信息是否应该与已经存在的目录信息相匹配。

数据管治（Data Governance）指的是企业使用的数据的有效性、可用性、一致性和安全性的总体管理。一个强大的数据管治程序将包括一个中央实体或委员会来创建管治规则、一套流程和一个完成这些流程的规划。与数据管理不同的是，数据管理是数据管治主体策略的一次战术执行。

客户数据整合（CDI）是整合和管理不同来源的客户信息的过程。客户信息可能包括合同细节、客户评估数据和通过交互收集的信息（如，直接销售）。如果实施恰当，CDI可以保证组织中所有相关部门能够持续访问最新和最完整的客户信息。因此CDI是客户关系管理（CRM）的一个至关重要的元素。

MDM中心是一个数据库及管理数据库中主数据的软件并保持它与使用主数据的事务系统同步。关于MDM中心的最常见问题是“MDM中心是否能够同时处理客户和产品数据?”。

根据MDM专家Jill Dyché的观点，不同类型的MDM体系结构都有特定的优点和缺点。MDM体系结构风格包括持久化、注册、混合、共存和事务。

根据MDM专家意见，诸如“协作的”和“分析的”MDM的词汇都只会混淆MDM的功能。开发MDM的动因是主数据是如何存储、访问和传播到企业中的。而且，如果数据用法给MDM增加了复杂性时，第二个动因就是组织使用和管理它的主数据的方式。

在实现MDM系统后，专家建议不要太担心MDM投资回报（ROI）。相反，重要的是你的实现是如何解决公司的数据管理问题，以及MDM系统是否有助于节省业务规划的开支。

MDM项目可能是一项复杂的工作，但如果有合适的专业人员可以使项目变得很顺利。主要的MDM人员包括以下MDM角色：高级管理、业务客户、应用负责人、信息架构师、数据管治和数据质量人员、元数据分析师、系统开发人员和运营人员。

企业组织管理（Enterprise hierarchy management）是公司更新、建模和维护信息层次（如，客户和/或产品信息）的地方。以前，当业务发生变化，如收购或重组，有关的组织层次必须在不同的分析系统中更新以使报告精确。然而，新产品提供了一个独立部分来完成所有必需的修改，这些修改被发布到多个商业智能（Business Intelligence，BI）或企业绩效管理（Corporate Performance Management，CPM）软件系统。

开发一套MDM度量来测量和演示MDM对于一个公司的影响是MDM项目成功的关键。然而，根据Gartner Inc.分析师John Radcliffe的观点，这些度量应该关注于业务，而不是IT。比如，显示MDM有助于增加客户数据10%准确性的度量是不太可能影响到管理的;然而，显示客户保有和/或越区销售率增加的度量将会产生很大的影响，因为它们是业务成功的关键。

数据职能中心，或者称为数据管理职能中心，是一个组织内的一个小组（一般是一组以数据为中心和有数据处理能力的专家），它为MDM制定策略和流程，并帮助在公司内部实施这些MDM规则。

本文链接

构建一个主数据管理(MDM)的解决方案

2011-07-21T02:57:00Z

　如何构建一个主数据管理(MDM)的解决方案

在开始构建主数据管理(MDM)解决方案之前，首先需要明确我们当前的数据管理现状是什么样子的，而我们的目标是什么，具体可以参照上一小节：主数据管理(MDM)的成熟度。

第二步，需要确定我们的每个主数据域的范围(这也是前期需求分析的一部分)。常见的主题域有：

Party ：可以反映任何合法的实体，无论是个体还是组织。

Product ：既包括物理存在的货物，也可以是任何服务。

Account ：包括期限和条件，以及相关的各种关系。

Location ：既可以独立存在，也常常与其他主数据域共存。

第三步，进行数据管理系统的设计，在设计时要注意以下几点：

数据采集和发布是否实时，最小的响应时间是多少。

数据转换规则能否让客户定制，而不是硬编码。

如果根据数据质量标准清理主数据域中的主数据。

权限控制。

主数据的历史版本控制以及变更监控控制(当主数据变化时，要能记录该变化，另外还要对主数据形成层次并记录其不同的版本值)。

第四步，开发部署测试。

本文链接

MDM 介绍二主数据管理(MDM)的成熟度

2011-07-21T02:33:00Z

主数据管理(MDM)的成熟度

根据主数据管理实施的复杂程度，参照Jill Dyche， Evan Levy的观点大体可以把主数据管理可以分为五个层次，从低到高反映了主数据管理(MDM)的不同成熟度。下面我们简单介绍一下这五个层次：

　 Level 0 ：没有实施任何主数据管理(MDM)

在Level 0的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。比如，一个公司销售很多产品，对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。在Level 0，每个独立的应用负责管理和维护自己的关键数据(比如产品列表、客户信息等)，各个系统间不共享这些信息，这些数据是不连通的。

Level 1 ：提供列表

不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户需要某些数据的时候，就可以索取该列表了。对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。业务规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦某人缺席，将会影响列表的维护。

MDM Level 1比MDM Level 0的不同就是，各个部门虽然还是独立维护各自的关键数据，但会通过列表管理维护一个松散的主数据列表，能够向其他各个部门提供其需要的数据。在MDM Level 1中，数据变更决定以及数据变更操作都是由人来决定的，因此，只有人完成数据变更决定后才会变更数据。在实际情况中，虽然数据变更流程有严格的规定，但是由于缺乏集中的、基于规则的数据管理，当数据量比较大时，数据维护的成本会变的很高，效率也会很低。当主数据，比如客户信息、产品目录信息等数量比较少时，列表管理的方式是可行的，但是当产品目录或客户列表出现爆炸式增长以后，列表管理的变更流程将变得困难起来。MDM Level 1 依赖于人的协作。如果产品经理需要更新过后的产品价格列表，那需要联系ERP系统所有者，让其发送邮件给她。在企业范围内实现客户或产品列表就如同维护不同部门之间人们的关系一样。如果客户或产品存在层次或分组，列表将很难提供，并且通常在Level 1因为过于复杂难以被管理。

Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联)

MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。通过建立数据标准，定义对存储在中央知识库(Central Repository)中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库(Central Repository)通常会被称为“主数据主机(Master Data Host)”。这个知识库可以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。

创建、读取、更新和删除 (CRUD)是处理基本功能的典型编程术语。即便在MDM中，CRUD处理也是基本功能。你的数据库如果仅仅支持CRUD处理并不意味着你实现了MDM。 MDM Level 2引入了“同等访问”(peer-based access)，也就是说一个应用可以调用另一个应用来更新或刷新需要的数据。当CRUD处理规则定义完成后，MDM Level 2 需要客户或“同等”应用格式化请求(和数据)，以便和MDM知识库保持一致。MDM知识库提供集中的数据存储和供应(provisioning)。在这个阶段，规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。

比如，一个数据库或一个打包应用(比如一个销售自动化系统)对外部应用提供数据访问功能。当一个外部应用(比如呼叫中心应用)需要增加一个客户，这个外部应用将提交一个事务，请求数据所有者增加一个客户条目。主数据主机(Master Data Host)将增加数据并告知外部应用。CRUD处理方式比纸上办公有了很大提高，其是基于会话的数据管理。在MDM Level 1，数据变更是基于手工的方式。在MDM Level 2，数据变更是自动完成的—通过由具体技术实现的标准流程，允许多应用系统修改数据。MDM Level 2可以支持不同的应用使用和变更单一、共享的数据知识库。MDM Level 2 需要每个同等应用理解基本的业务规则以便访问主列表、与主列表进行交互。因此，每个同等应用必须正确恰当地创建、增加、更新和删除数据。授权应用有责任坚持数据管理原则和约束。

Level 3 ：集中总线处理

与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据(MDM Level 2的主数据主机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起)。

集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。 MDM Level 3 集中数据访问、控制跨不同应用和系统使用数据。这极大的降低了应用数据访问的复杂性，大大简化了面向数据规则的管理，使MDM比一个分散环境具有更多的功能和特点。企业主数据面临一致性的挑战。数据在不同的地方存在，数据所代表的含义也是不同的，数据的规则各个系统之间也是不一样的。集中MDM处理-通过一个公共的平台作为一个总线(HUB)-说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其在源系统中是什么样子，都会被整合起来。在MDM Level 3，公司对主题域内容采用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。MDM Level 3支持分布主参考数据的存在。

MDM的核心之一就是保证所有系统都能接受数据表示的唯一公认方法。这有点类似于语言翻译，通过其他语言的翻译，英语已经称为一个全球性的语言。在MDM Level 3，一个公司可以让任意两个系统共享数据和说对方的语言。MDM Level 3还降低了等同访问的复杂性。"消费"应用不再需要支持系统定位和操作逻辑。任何与源系统数据相关的分布式细节都会被MDM总线集中处理。在MDM Level 3自动数据标准意味着：建立目标数据值表示和通过必要的步骤提供精确的主数据值捕获。在所有的分类中从MDM Level 3开始第一次支持一致性的企业数据视图。数据质量规则在这里进行数据清洗和错误纠正。

Level 4 ：业务规则和政策支持

一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本。当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是：“证明它”。MDM Level 4可以保证主数据反映一个公司业务规则和流程，并证实其正确性。MDM Level 4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。由于多数公司相对比较复杂，影响业务数据访问和操作的规则以及策略 (rules and policies)相对也比较复杂。假定任何一个单一系统可以包含并管理与主参考数据相关的各种类型的规则是不切实际的。因此，如果一个MDM总线真正打算提供企业范围内数据的精确性，工作流和流程整合的支持是必不可少的。

举例来说，在一个HMO内，需要多个应用来支持一个病人的护理。一个单一的访问(visit)可能包括入院、房间和床位分配、监控设备、化验、身体检查以及其他程序等。一旦一个病人准备离开医院，出院流程需要确保和这个病人相关的所有活动、资源都被结清。MDM技术在召集多个应用系统一起保证病人辨识方面是十分有效的，处理是正确的。虽然病人辨识很重要，业务规则整合同样重要。临床系统依靠一系列的业务流程和数据规则来辨别所有显著的病人详细资料。这包括返回所有基于房间的资源(监护设备、床位等)以得到有用的详细目录，当病人要出院时分解其所有的费用。MDM保证当John Smith出院时，正确的房间和设备放入到该John Smith的详细目录中，而不是其他的John Smith(正在另一个楼层做身体治疗)。

MDM系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。这些规则可能包括通过总线与临床系统交互或等待另一个系统或者人(有权限做出改变的人)审批。通过一个MDM总线，规则定义可以不仅局限在逻辑上，还可以依赖于其他系统的输入。当然，协调和审计数据意味着可以回退其他系统(或业务流程)来保证数据变化经过严格的审批，这样错误可以被发现并且事务在需要的时候可以被回滚。MDM Level 4提出对规则和策略扩展性的支持。通过总线以一个灵活可持续的方式支持任何面向业务的规则集合这很重要。

比如，如果一个商店经理更新一个产品的价格，总线系统需要能够和一个可信系统(比如，商品管理系统)进行协商以便使规则生效。详细规则将支持另一个系统中存在产品价格的变更—总线需要能够理解能够处理和批准变更的权限系统或方法。这些规则可能涉及到复杂性或隐私限制，禁止它们直接在总线上存在。在MDM Level 4，一个企业可以支持一套步骤或任务，在一个特殊的创建、读取、更新和删除任务被允许之前这些步骤或任务必须遵守。工作流自动化经常用来支持发生在总线上的事件或活动的授权。但是变更管理远远不仅仅是工作流：它可以包括基于逻辑的流程和基于人的决策。变更管理的存在可以支持动态业务，允许变更。举例说明，在 911之前，任何人都可以在美国国内的航空公司运载货物。没有规定以外的其他某种形式的鉴定和付款方式。911之后，美国联邦航空协会(FAA)指导建立了一个更加全面的规定，指示一个人是否被允许运载货物。在这个特殊的例子中，要求各个系统都部署FAA对托运人的要求是不现实的。部署一个规则管理系统，为所有的系统(包括MDM总线)集中托运人批准规则，更加容易实现(也更现实)。集中数据定义和标准化在MDM Level 2就已经引入，与MDM Level 4的集中规则管理相比，相对简单。业务流程越复杂、业务流程越多，对总线的需求就越多，以便对针对共同数据的跨职能、异构规则进行更好的支持。重要的是 MDM Level 4支持集中规则管理，但是规则本身和相关的处理是可以分开的。换句话说，MDM总线需要保证规则是集中应用的，即便这个规则是在总线外居住的。

Level 5 ：企业数据集中

在MDM Level 5 ，总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。他们是一体的。当主数据记录详细资料被修改后，所有应用的相关数据元素都将被更新。这意味着所有的消费应用和源系统访问的是相同的数据实例。这本质上是一个闭环的MDM：所有的应用系统通过统一管理的主数据集成在一起。在这个级别，所有在系统看起来都是事实的同一个版本。操作应用系统和MDM内容是同步的，所以当变更发生时，操作应用系统都将更新。在那些熟悉的MDM架构风格中，持久总线架构，当一个总线更新所有的操作应用系统将体现这种变更，形成改变的直接操作视图。在注册环境中，当数据数据更新时，总线将通过Web服务连接相关系统应用事务更新。因此，MDM Level 5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个变更。系统更新完数据值后不要单选其他系统中相应值的更新：MDM将使这种更新变的透明。

从MDM Level 4到MDM Level 5意味着MDM功能性不是在一个应用内被特殊设计或编码的。这还意味着主数据传播和供应不需要源系统专门的开发或支持。所有的应用清楚的知道他们并不拥有或控制主数据。他们仅仅使用数据来支持他们自己的功能和流程。由于MDM总线和支持的IT基础架构，所有的应用可以访问主参考数据。一个公司在完成MDM Level 5后将使他们所有的应用连在一起—既包括操作的也包括分析的—所有访问主数据是透明的。举例说明，当一个客户更新她的状态—不要管注册该变更的系统—数据变更将被广播到所有的应用平台(因此一致起来)。MDM Level 5是把数据概念作为一种service来实现。MDM Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事。MDM Level 5移走了主数据的最后一个障碍：统一采用数据定义、授权使用和变更传播。

本文链接

MDM 介绍一

2011-07-21T02:26:00Z

什么是主数据管理(Master Data Management ，MDM)

主数据是指在整个企业范围内各个系统(操作/事务型应用系统以及分析型系统)间要共享的数据，比如，可以是与客户(customers)，供应商(suppliers)，帐户(accounts)以及组织单位(organizational units)相关的数据。主数据通常需要在整个企业范围内保持一致性(consistent)、完整性(complete)、可控性 (controlled)，为了达成这一目标，就需要进行主数据管理(Master Data Management ，MDM)。需要注意的是，主数据不是企业内所有的业务数据，只是有必要在各个系统间共享的数据才是主数据，比如大部分的交易数据、帐单数据等都不是主数据，而像描述核心业务实体的数据，而像客户、供应商、帐户、组织单位、员工、合作伙伴、位置信息等都是主数据。主数据是企业内能够跨业务重复使用的高价值的数据。这些主数据在进行主数据管理之前经常存在于多个异构或同构的系统中。

主数据管理(Master Data Management ，MDM)是指一组约束和方法用来保证一个企业内主题域和系统内相关数据和跨主题域和系统的相关数据的实时性、含义和质量。这是从深层次来说来说明主动主数据管理(MDM)的深度和复杂性，简单的说，主数据管理(MDM)保证你的系统协调和重用通用、正确的业务数据(主数据)。通常，我们会把主数据管理作为应用流程的补充，通过从各个操作/事务型应用以及分析型应用中分离出主要的信息，使其成为一个集中的、独立于企业中各种其他应用核心资源，从而使得企业的核心信息得以重用并确保各个操作/事务型应用以及分析型应用间的核心数据的一致性。通过主数据管理，改变企业数据利用的现状，从而更好地为企业信息集成做好铺垫。

主数据管理(MDM)可以帮助我们创建并维护整个企业内主数据的单一视图(Single View)，保证单一视图的准确性、一致性以及完整性，从而提供数据质量，统一商业实体的定义，简化改进商业流程并提供业务的响应速度。从变化的频率来看，主数据和日常交易数据不一样，变化相对缓慢，另外，主数据由于跨各个系统，所以对数据的一致性、实时性以及版本控制要求很高。

主数据管理其实在很早之前就一直存在，只不过现在随着业务发展以及监管的需要，对主数据的实时性、准确性、一致性有了更高的要求，才被业界广泛接受，各个厂商相应的推出了一系列的主数据管理集成与基础套件以及特定领域的解决方案。近年来最明显的变化是，客户在以前的时候经常问的问题是：“主数据管理是什么？”，而现在客户经常问的问题演变成了：“我们的业务的确存在一些问题，主数据管理正好可以解决这个问题，我们怎么开始？”。与以前相比，客户对主数据管理(MDM)的认识有了巨大的进步，并开始尝试用主数据管理(MDM)解决他们在整个企业范围内进行跨业务、跨主题域时遇上的各种挑战和问题：比如税务行业，税务局在按纳税人在一些分析统计时，就发现关于纳税人的基本信息分布在核心征收管理系统、发票管理系统、个人所得税系统、增值税管理系统等多达几十个系统中，使得统计分析变得困难起来，在比如在医疗设备公司，由于没有按照供应商进行产品层次的分类，各个产品的描述也很不一样，使得产品目录的维护十分困难。随着业务的发展，对各行各业来说，生成并维护一个统一的主数据系统变的十分迫切和必要，特别是对一些跨国公司，如何在不同的地区(各个国家和地区) 的业务系统之间维护关于客户、产品目录、供应商等信息的单一视图更是重要。

需要注意的是，主数据(Master Data)和元数据(Meta Data)是两个完全不同的概念。元数据是指表示数据的相关信息，比如数据定义等，而主数据是指实例数据，比如产品目录信息等。比如，某省地税开发了一套征收管理软件，以市为单位部署了17套，每套征收管理软件中的元数据都是一样的，但是主数据还是需要进行管理的。主数据管理和传统数据仓库解决方案不是一个概念，数据仓库会将各个业务系统的数据集中在一起在进行业务的分析，而主数据管理系统不会把所有数据都管理起来，只是把需要在各个系统间共享的主数据进行采集和发布。相对于传统数据仓库解决方案的单向集成，主数据管理正注重将主数据的变化同步发布到各个关联的业务系统中(主数据管理数据是双向的)。

　主数据管理问题存在的根源

对于大多数的企业都存在主数据管理的问题，个人以为这是由于业务发展的渐进性以及IT技术发展的渐进性造成的，正是由于这种渐进性，各大企业的业务系统从经历了从无到有，从简单到复杂，从而形成了一个又一个的业务竖井。从根本上来说，不可能只使用一个业务系统就能覆盖企业的所有业务，即便对一些国际大型的公司提供的套件来说也是一个不可能完成的任务(即便对套件来说，经常也存在一个跨国企业在不同的国家或地区部署多个实例的现象，也就是没有集中部署该套件，而是在很多地方分散部署了该套件)。对企业来说，业务系统的构建更多是以项目为中心，从下而上的构建系统，而不是至上而下的构建系统，必然缺乏整个企业范围内的统一规划，从而使得一些需要在各个业务中共享的数据(主数据)被分散到了各个业务系统进行分别管理。分散管理的主数据由于没有不具备一致性、准确性、完整性，使得各个企业普遍存在着产品管理不力、供应商管理不力、订单管理不力等现象。解决这一问题的根本方法就是引入主数据管理(MDM)，主数据不光指需要共享的数据，更包含需要共享的业务规则和策略。

本文链接

主数据管理（MDM）的七个最佳实践

2011-07-21T02:02:00Z

主数据管理（MDM）的七个最佳实践

[ 14/09/2009 15:48:00 | By: pegem255 ]

来自网络：http://www.folo.cn/user1/19092/archives/2009/74818.html

在考虑像主数据管理（MDM，Master Data Management）这样的学科时，寻找已经经历过或做过主数据管理的过来人咨询是唯一自然的途径。　　

但是主数据管理可能最佳实践仍处于起步阶段仍然显现出来了，因为让有经验的机构去讲他们主数据管理的经验不是一件容易的事。Kalido公司是一家马萨诸塞州伯灵顿的主数据管理技术供应商，该公司也认为让客户对新闻界讲这方面的话题是很困难的。

所有成功的主数据管理项目都保密，因此对企业寻找最佳实践不太容易没有好处，这也是Kalido为什么发起一次客户审计和主数据管理最佳实践研究（由加州圣马特奥分析公司Ventana研究院研究）的部分原因。其研究员调查了五个Kalido匿名客户的最佳最终实践来推导结论。为了主数据管理的成功，Ventana研究所，一个有经验的顾问和一家欧洲电信制造商最终提供了一些最佳实践（和最差实践）。

1. 让业务参与进来（或者在管理下进行）。

“主数据管理必须由企业需求驱动，否则它可能变成为一个只是必须与所有其他数据库同步的另一个数据库”，David Loshin说。他是马里兰州银泉Knowledge Integrity公司的总裁，该公司提供主数据管理策略开发服务咨询以及从事企业级策略研究工作。

同样，Ventana研究发现，推动主数据管理进程的应该是业务人员，而不是IT人员。Ventana发现，要想获得主数据管理成功，从C级主管到高级管理者到业务终端用户的广泛支持是至关重要的。我们常常很难激励组织向着主数据管理干巴巴的前景迈进，但是从长远来看，早点开始企业范围内的支持是很重要的，用户们说。如果公司的重要目标通过一个稳定的商业案例绑定了该项目，那证明它的利益和激励士气的任务应该就简单了。

2. 允许使用充足的时间评估和计划。

Kalido用户告诉Ventana研究员们说，要计划至少为期三个月的评估，与相关客户交谈，用真实的公司数据做例子做一个价值验证项目。用户们说，不要低估了时间和开发基础数据模型的过程。

“这事比人们想象的更复杂——而且它需要及早开始，并且计划使用真实数据”，David Waddington说，他是Ventana的一位副总裁兼研究主管，一直在从事这项研究。

Ventana发现，IT公司的合作是一个令人关切的领域，因为一些公司曾经经历过由于许可和访问权限导致的项目延迟。

3. 定一个大目标，但采取小步骤。

用户们告诉Ventana，要考虑基本目标，但是会限制战略部署的视野。他们建议，一旦主数据管理在一个地方好用了，再一步一步地扩展。他们说，业务流程常常是缓解因素，而不是技术，所以在过程中及早得到终端用户的输入时很重要的。

“如果你只对保持客户数据一致性感兴趣，那就一定要反对‘怎样我才能长期管理我全部的主数据?’这一大前提，这一点是很重要的”,Waddington解释到。“那样你最后就不会落到不得不把整个一大堆解决方案连接到一起的困境中。”

4. 考虑潜在的性能问题

Loshin警告说，性能像一只800磅重的猩猩悄悄潜伏在主数据管理的探讨中。

不同的架构能导致不同的性能损失。例如，如果公司为主数据管理采用主hub方式，记录创建流经唯一一个点，它就能变成一个瓶颈。而且，随着应用越来越依赖主数据管理，工作流，系统优先级和运行顺序会变成要马上考虑的紧急问题。Loshin说，公司怎样解决潜在的性能问题有多种选择，因为它本质上与他们独特的架构有关系。

5. 建立数据管理策略和流程。

专家们一致认为，应该允许在人力和过程变更管理方面花时间和投钱，不要低估了工作量。瑞典电信设备制造商爱立信公司了解到，根据高级项目经理Roderick Hall的观点，数据管理政策可能是相当难满足的。

在部署SAP主数据管理很早以前，斯德哥摩尔的公司建立了一个主数据小组来管理关键数据资产。它是一个“共享服务”小组，同时对IT和商业提供服务。该组刚成立时是财务部门的一部分，但是随着主数据管理受到公司范围的关注，它的职能也发生了变化，Hall说。他们的工作并不总是很容易。

Hall说，尽管一些部门（比如财务部门）看到了集中主数据管理的价值，其但他群体都不太乐意放弃自己管理数据的权利。

“人们已经放弃了自己管理数据的自由，把他们自己的主数据放到斯德哥摩尔（在那里主数据小组是本地的）一些不露面的组织。为了得到人们对这一事实的认可，他们真的打了一场硬仗”，Hall说。

6. 仔细计划部署。

Ventana发现，主数据管理相对仍然比较新，所以对业务和技术人员的培训比以往更重要。Waddington说，使用未参加培训的或者是准培训的系统集成人员和

尝试外包，对主数据管理用户来说，会引起大问题，甚至项目延期。

7. 考虑过渡计划。

那么，有了铺开项目的前景，该项目会对关键流程和系统造成一定影响——没有无缘无故的担心。Loshin推荐公司应该计划一个主数据管理的过渡策略，允许静态和动态的数据同步。

“试图在不影响日常操作的前提下调整潜在的基础设施，可能与不中断交通的情况下在公路上补洞一样具有挑战”。Loshin说。

本文链接

如何用正确的方法来写出质量好的软件的75条体会

2011-07-12T05:16:00Z

1. 你们的项目组使用源代码管理工具了么?

应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

2. 你们的项目组使用缺陷管理系统了么?

应该用。ClearQuest太复杂，我的推荐是BugZilla。

3. 你们的测试组还在用Word写测试用例么?

不要用Word写测试用例(Test Case)。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP .NET的小网站。主要目的是Track和Browse。

4. 你们的项目组有没有建立一个门户网站?

要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么?

应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。

6. 你们的程序员工作在安静的环境里么?

需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。

7. 你们的员工每个人都有一部电话么?

需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。

8. 你们每个人都知道出了问题应该找谁么?

应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说“我以为…”么?

要消灭“我以为”。Never assume anything。

10. 你们的项目组中所有的人都坐在一起么?

需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。

11. 你们的进度表是否反映最新开发进展情况?

应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

12. 你们的工作量是先由每个人自己估算的么?

应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。

13. 你们的开发人员从项目一开始就加班么?

不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?

不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

15. 值得再多花一些时间，从95%做到100%好

值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

16. 登记新缺陷时，是否写清了重现步骤?

要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。

17. 写新代码前会把已知缺陷解决么?

要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。

18. 你们对缺陷的轻重缓急有事先的约定么?

必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

19. 你们对意见不一的缺陷有三国会议么?

必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么?

Bug应该由Opener关闭。Dev不能私自关闭Bug。

21. 你们的程序员厌恶修改老的代码么?

厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

22. 你们项目组有Team Morale Activity么?

每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。

23. 你们项目组有自己的Logo么?

要有自己的Logo。至少应该有自己的Codename。

24. 你们的员工有印有公司Logo的T-Shirt么?

要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议

要的。要让team member觉得高层关注这个项目。

26. 你们是给每个Dev开一个分支么?

反对。Branch的管理以及Merge的工作量太大，而且容易出错。

27. 有人长期不Check-In代码么?

不可以。对大部分项目来说，最多两三天就应该Check-In。

28. 在Check-In代码时都填写注释了么?

要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

29. 有没有设定每天Check-In的最后期限?

要的，要明确Check-In Deadline。否则会Build Break。

30. 你们能把所有源码一下子编译成安装文件吗?

要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。

31. 你们的项目组做每日编译么?

当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表?

要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

33. 设计越简单越好

越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码

千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件;尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么?

要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。

36. 你们的项目组每个人都写Daily Report么?

要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己(要是游手好闲一天，自己都会不好意思写的)。

37. 你们的项目经理会发出Weekly Report么?

要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

38. 你们项目组是否至少每周全体开会一次?

要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

39. 你们项目组的会议、讨论都有记录么?

会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么?

要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通

Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group

如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。

43. 每个人都知道哪里可以找到全部的文档么?

应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。

44. 你做决定、做变化时，告诉大家原因了么?

要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。

45. Stay agile and expect change

要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员?

要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么?

这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段，自动的还是手动的?这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么?

应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例?

不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么?

要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试?

要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么?

别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么?

不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么?

虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

55. 你们项目组中有人能说出产品的当前整体质量情况么?

要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。

56. 你们有单元测试么?

单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么?

大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

58. 你们的程序中所有的函数都有输入检查么?

不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

59. 产品有统一的错误处理机制和报错界面么?

要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么?

要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。

61. 你们的每个人都了解项目的商业意义么?

要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

62. 产品各部分的界面和操作习惯一致么?

要这样。要让用户觉得整个程序好像是一个人写出来的那样。

63. 有可以作为宣传亮点的Cool Feature么?

要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

64. 尽可能缩短产品的启动时间

要这样。软件启动时间(Start-Up time)是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象

程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

66. 你们根据详细产品功能说明书做开发么?

要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

67. 开始开发和测试之前每个人都仔细审阅功能设计么?

要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么?

要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

69. Dev工作的划分是单纯纵向或横向的么?

不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。

70. 你们的程序员写程序设计说明文档么?

要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

71. 你在招人面试时让他写一段程序么?

要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。

72. 你们有没有技术交流讲座?

要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么?

要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间;另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么?

会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。

75. 尽量不要用Virtual Heads

最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。

本文链接

ESB——企业服务总线没有神话

2011-03-07T02:36:00Z

在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（SOA）的相关问题、如何让企业服务总线（ESB）作为构建企业SOA框架的主干问题等。其中，许多人质疑ESB的意义所在，从中也体现出当前IT群体普遍对ESB存在一定的误解。

在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（SOA）的相关问题、如何让企业服务总线（ESB）作为构建企业SOA框架的主干问题等。其中，许多人质疑ESB的意义所在，从中也体现出当前IT群体普遍对ESB存在一定的误解。下面便是笔者总结人们最关心的10个ESB的问题。

误区1：ESB只是EAI换了个名字
　　许多IT架构团体在搭建SOA的同时仍然受到一个问题的困扰：“ESB和EAI到底有什么不同？”ESB是一种用于构建企业SOA的基础设施，它比传统的EAI代理的用途更为广泛。根据福里斯特研究所的报告，ESB可以提高连通性、增加灵活性促进发展、并加强对重要资源的控制，从而帮助企业实现SOA 的价值。
　　ESB不仅可以用于处理以往依靠EAI工具进行的集成项目，还可以用于建立企业间的B2B关系。
　　ESB可以提供EAI所能提供的功能，但其基本架构是不同的：这个架构促进了企业从传统的集成方式转向协调服务交互。EAI通常是采用星形架构以独立应用的形式实现的。
　　ESB提供的功能与EAI代理相同--连通器、应用适配器、根据规则进行的消息路由和数据转换引擎--但是这些功能是面向SOA的，它们分布于整个服务总线并寄存在可独立部署的服务容器中。这使我们可以有选择性地部署所需的集成代理功能，不会产生冗余。ESB容器模型的这种分布式特性使以事件驱动服务的形式按需添加到SOA中的集成组件具有独立的可扩展性。
　　为了使集成代理能够从真正意义上支持SOA并成为真正意义上的ESB，我们需要把它的基本功能分散到组成部件中，然后才能将各个组件独立地部署到总线中，并使它们协调运作。
　　我们来看一个基于XSLT的转换引擎。该引擎可以根据XSLT模式表把一种XML文件转换为另一种XML格式。我可以负责任地告诉你没有什么比分析和处理XML更消耗计算资源的了。如果两个经常互通的应用之间存在XSLT转换，那么这个转换很可能会成为性能与扩展的瓶颈。如果你采用的是独立式的星形集成代理方式，那么为了解决这个瓶颈问题并扩大部署你必须把这个集成代理安装到一个处理能力强大的机器上，或者是安装到多台机器上--而这仅仅是为了解决这个转换的问题。同时，其它的集成代理功能，比如路由规则的处理还在和转换处理抢夺计算资源。
　　与集成代理的星型架构不同，ESB的基础核心提供了一种分布式的服务架构。这种架构是面向集成的，它可以对集成代理中的各种功能比如消息路由、数据转换、和应用适配器等进行选择性的按需部署，而这些独立的集成服务正是构成SOA的一部分。
　　可以把XSLT转换以服务的形式部署到ESB服务容器中，然后把这个容器的多个实例根据负载平衡分布到许多机器中。如果这个ESB容器是跨平台实现的，那么你还可以灵活地选择转换服务所跨越的平台--Linux主机、Solaris主机、Windows主机等等。如果你不喜欢这种简单的架构，还可以这样考虑：那些对ESB的定义和产品提出非难的供应商同时也为我们提供了方便：你可以部署任意多的轻量级ESB服务容器而无需支付任何额外费用。
　　ESB提供的这种集成服务可以与其它服务结合融进基于SOA的处理流程，从而扩大业务范围。ESB中的分布式服务可以结合基于路线（itinerary-based）的路由选择（见误区#7）以实现自定向、面向消息的服务交互，从而使ESB的各个部件能够独立地进行工作，不会对某个集中式的路由引擎产生依赖。

　误区2：微软正在利用"Indigo"创建ESB
　　微软的Indigo结合了Messaging Queuing、Component Object Model COM+、.NET、和Web服务。他们在做的是具有Web服务扩展功能的消息总线。这和企业服务总线是有很大不同的。消息总线暴露了低层消息技术的详细内容，它需要编写代码来定义应用与服务之间的关系。而ESB的意义在于配置而不是编码，因此也不需要手工编写内部互通的的各应用之间的关系。ESB有利于提高以事件驱动的形式暴露于总线上的应用之间的松耦合特性。好消息是Indigo上创建的应用至少也是基于消息的，因此通过ESB进行集成也会比较简单。
　　也就是说，BizTalk Server中的某些东西与Indigo组合后可能会比较像ESB。不过还有很重要的一点，即BizTalk是星型集成代理，因此它同样受到前面在ESB 与EAI中所提到的所有不利方面的影响。你无法在不增加任何费用的前提下把XML转换引擎从BizTalk Server中分离出来并作为负载平衡的服务运行在多台机器上（详见前面EAI与ESB的讨论）。

误区3：WS-Rliability和WS-Reliable Messaging等WS-*标准终将解除对ESB的需求
　　在设计ESB的时候就应该考虑使其能根据这些不断发展并逐渐获得商业应用价值的标准做出调整。WS-*标准的发展使应用终端能更好地通过ESB进行交互。
　　由于各种平行进行的工作，WS-*标准作为不断发展的Web服务标准的一部分自然也存在许多不确定因素。即使这些标准最终发展健全并且得到了广泛的应用，它们仍然需要一个能够为其提供支持的平台。ESB可以在与底层协作标准无关的层面上为企业提供一个构建、编排和管理SOA的统一模型。
　　WS-Reliability标准的实施需要有可靠的消息持久性和存储转发处理器的支持。企业消息层是ESB的基础组件，它通过消息持久性、存储转发、消息验证等消息协议和与外部XA-compliant事务处理器的接口保证数据传输的服务质量。ESB的部署还可能使复杂网络布局的消息路由透明化，并通过容错的消息服务器架构实现消息设施的持续可用性。在当前高压的企业环境下，要实现所有这些设计还需要许多人的多年劳动。
　　也就是说，现在部署具有专有消息层的ESB时还应该同时采用一种或更多的WS-Rel*作为补充协议以为将来作准备。但是，这并不是一种可以解决所有问题的方案，我们仍然需要对多种消息和协议的组合提供支持。

　误区4：模式还是产品？
　　企业服务总线（ESB）这个术语实际上并不属于产品的范畴；它只是一个可以实现应用服务器与集成中间件的耦合关系的抽象概念。
　　ESB是一个用于构建企业SOA的高度分布化的主干总线。企业要构建面向服务的架构，而ESB则是这个架构的基础总线。由于ESB的产生对集成市场带来不少冲击，某些集成供应商便放出烟雾弹称ESB只是一个可以用于组合当前的中间件与应用服务设施的抽象的模式。实际上，ESB确确实实地是一种硬件设施，而且几年前就已经可以从各供应商处购买到了。目前为止，制造业、金融业、电信和零售等各产业之间已经部署了许多ESB。
　　ESB的定义应该包含以下基本要素：
　　· 一个分布式的服务架构，包括一个用于寄存集成组件作为远程服务的轻量级容器模型
　　· 一个可以为各应用与服务提供可靠的消息传输的企业消息主干总线
　　· XML Data转换
　　· 服务编排和根据消息内容进行处理的智能路由
　　· 一个灵活的安全架构
　　· 可以配置、部署、监控以及管理远程服务的管理设施
　　由于ESB的分布式服务架构，我们可以通过全球任何位置上的虚拟终端访问服务。这个分布式服务架构是建立在一个由可以通过远程服务进行配置、部署、管理和监控的轻量级服务容器构成的互联系统上的。这些服务容器通过一个实现了可扩展性、持续可用性、低延时处理、安全一致和服务质量（QoS）的标准化的消息主干总线组合到一起。

　误区5：ESB与J2EE应用服务产品之间存在竞争
　　ESB与J2EE app服务器是高度互补性质的。通过使用JMS、MDB、JCA或Web服务等标准接口连接到ESB，即使是在非J2EE环境下J2EE app服务器也可以与其它应用服务器很好地集成。
　　大部分ESB用户同时也是应用服务器技术的用户。这些用户利用应用服务器和ESB作为他们的集成环境的最优组件--使用应用服务器寄存业务逻辑并以门户的形式提供网站服务，同时使用ESB来集成应用服务器与企业中的各种后端应用和数据源。

误区6：只要使用Web service call即可把门户网站连接到后端系统上
　　虽然理论上Web服务调用可以把门户连接到后端目标系统上，可是这种方式无法扩展到多个后端系统上。通过使用ESB，可以让门户服务器通过唯一的接口连接到总线，而总线则成为门户服务器可能调用到的所有后端系统上的各种连接属性、协议、安全和数据格式的媒介。
　　使用了ESB作为门户服务器和可能与门户服务器产生交互的各种后端应用的中间层相当于为ESB用户提供了一个更为灵活、扩展性能更好的SOA，因此当项目更成功、根据业务需求需要发生变化时，他们也能自由地处理各种各样的集成作业。

　误区7：当BPEL获得广泛应用的时候ESB就会退出舞台
　　ESB可以支持多种事件驱动的服务调用的编排方式。BPEL只是其中的一种。ESB还有基于路线的路由，可以为消息指定一系列的路由指令。消息因被服务调用而经过总线的时候，这些代表业务过程定义的路由指令始终是和消息绑定的。然后由远程ESB服务容器决定将消息发送到哪里。
　　这个过程中没有集中的路由规则引擎，因此基于路线的路由也是ESB分布式的特性一大体现。像星型EAI代理所用的这种集中的消息路由规则引擎则可能会成为系统的瓶颈，并且如果这一部分出现故障将导致整个系统的瘫痪。仅仅使用消息路线、消息和过程定义其实就足够了，这样还能允许ESB的各个不同部分独立地进行工作。
　　消息路线可以有效地处理那些包含有限步骤并且无需很长的处理时间即可结束的无状态随机过程。甘特称这种过程定义为"微流（microflows）"。根据基于内容的路由服务的使用情况，路线中可能会产生简单的分支。
　　如果需要更复杂的过程定义，还可以在ESB中加入一个流程编排引擎作为补充服务。这个过程编排可以支持可能存在很长时间的状态过程。它还可以支持带分支的平行执行路径，并根据联接条件或转换条件支持消息流执行路径的融合。这样的过程可以支持BPEL和其它的过程定义语法，比如ebXML BPSS。还可以将成熟的过程编排与非状态的基于路线的路由结合，建立一个可以解决复杂的集成问题的SOA。

　误区8：ESB技术和其它技术一样正在经历一个典型的技术发展曲线：凭空产生，迅速发展，然后马上进入“幻灭”阶段。
　　ESB这个概念是制造、电子商务、电信、金融服务和零售等多个产业的先导者共同努力产生的结果。其产生是由于需求，是以当时已经比较成功的分布式计算模型和EAI技术为基础建立的新方式。这些IT先导者的最终结果是一致的："我们的分布式消息基础结构是成功的，所以我们希望能以此为基础建立一个用于集成的基于标准的事件驱动的SOA。我们希望它能包含Web服务、XML数据转换、基于内容的路由和面向分布式过程的服务调用模型。"因此，ESB 中所体现的这些概念都是成熟的，是有健全的基础的。也正因为如此，ESB技术正在发挥着它应有的作用。现在已经有数百条ESB在各行业服役，比如供应链、物流自动化、金融服务中的全球直通处理、电信的实时服务、以及零售业的远程店面管理。

误区9：ESB只是一个推动器，但它并没有提供成熟的工具，比如设计业务流用的图形编辑器。
　　现在有一种新的IDE（或Gartner集团所称的ISE）可以让你设计、配置、测试、调试你在建立应用ESB的SOA时开发的集成服务。其使用的是图形界面，集成设计师可以用UML表示法来描述过程定义。你还可以使用ISE图形化地创建不同数据之间的转换方式并建立和调试XSLT模式表。

误区10：可以使用EJB容器实现ESB容器
　　ESB结构中的一个关键组成部分就是一个高度分布式的、轻量级的服务容器。这个服务容器能以事件驱动服务的形式寄存集成组件，比如一个在XML消息中添加XPath表达式来决定路由的基于内容的路由服务。它还能寄存定制的服务或用于接入打包的应用的专门适配器。
　　这和它们的远房亲戚应用服务器容器及集成代理可不一样，ESB服务容器可以让你随时在任何地方有选择性地按需部署集成服务，不多也不会少。而另一方面即使只需要添加一点集成功能都需要在所有地方安装完整的应用服务器堆栈。这样就产生了所谓的"到处都是应用服务器"的问题。同时还会产生数目不小的许可证、安装、和随后相关的各种费用。
　　而ESB的精髓在于"配置取代编码"。如果是以应用服务器为主的集成方式，你通常要编写代码来描述服务之间的依存关系。EJB模型使用的是 client/server的集成模式，服务之间的接口是紧耦合的关系，而这些都要写进代码并编译到类文件中，这样，每次需要改动的时候都要对这些文件进行修改和重新部署。
　　在ESB中，服务是以与输入和输出通道有关的信息进行配置的。这些通道发送和接收基于内容的请求和响应模式以及单向事件通知，然后通过其它的调用框架进行处理，而不是服务本身。
　　可以对ESB服务进行配置和部署，这只需要从配置仓库里读取XSL模式表、XPath表达式、脚本和参数等信息。一旦部署完成，其性能便是高度灵活的。

　　总结
　　总的来说，对ESB的理解包含以下方面：
　　· ESB是建立企业SOA集成环境的主干总线。
　　· WS-*标准的发展将使ESB的交互性能更为完善。今天采用ESB可以让你做好应付未来的准备，并且当WS-*标准具有真正的商业价值的时候你也能做出适当的调整。
　　· ESB并不仅仅是一个抽象的模式。它属于产品的范畴，有清晰的定义，也有许多供应商可以选择。
　　· ESB与应用服务器的互补性很强。
　　· ESB提供了灵活的连接器和可扩展的设施，有利于将门户服务器集成到后端系统。
　　· ESB为协调服务之间的交互提供了许多选择。
　　· ESB技术是以实际为基础的，并已在许多行业得到应用。
　　· ESB可以提供更高层次上的可视化工具在ISE环境下进行服务集成。
　　· ESB提供了一个轻量级、可配置、高度分布式的服务容器环境。

本文链接

ESB企业服务总线

2011-03-07T02:20:00Z

ESB是企业服务总线（Enterprise Service Bus）的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：

解耦中介：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。
服务中介：ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
服务编排：多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或代码级编排)。

从上面可以看到ESB的基本功能仍然是数据传输，消息协议转化，路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要 ESB提供这些功能。没有ESB时候也可以实现SOA，比如借助SCA和BPEL来实现SOA，当时却很难实现消息协议转化和动态路由。

ESB在发展过程中有从原有的消息中间件转化为ESB产品的，这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成，以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的，自描述的且能互操作的实体。

对于SOA关注的是服务全生命周期，通过服务实现业务价值。而ESB关注的是服务中介和服务的集成，是SOA的基础设施。SOA有两个核心组件，一个是 ESB，一个是BPEL，而ESB是基础设施，BPEL是业务流程驱动下服务的集成和整合。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。Bobby做了一个比喻：路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像一个没人使用的道路。

做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。

ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。

标准的 ESB 功能

通信	服务交互
路由寻址通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS）发布/订阅响应/请求 Fire-and-Forget，事件同步和异步消息传递	服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL））支持替代服务实现通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型）服务目录和发现
集成	服务质量
数据库服务聚合遗留系统和应用程序适配器 EAI 中间件的连接性服务映射协议转换应用程序服务器环境（例如 J2EE 和 .NET）服务调用的语言接口（例如 Java 和 C/C++/C#）	事务（原子事务、补偿、Web 服务事务（WS-Transaction））各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
安全性	服务级别
身份验证授权不可抵赖性机密性安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））	性能吞吐量可用性其他可以构成契约或协定的持久评估方法
消息处理	管理和自治
编码的逻辑基于内容的逻辑消息和数据转换有效性中介对象标识映射数据压缩	服务预置和注册记录、测量和监控发现系统管理和管理工具的集成自监控和自管理
建模	基础架构智能
对象建模通用业务对象建模数据格式库 B2B 集成的公共与私有模型开发和部署工具	业务规则策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy））模式识别

上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

支持 SOA 的最低功能的 ESB 实现

如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：

ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。
SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
ESB 可以作为分布式的异构基础架构进行实现。
ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

最低的 ESB 功能

通信	集成
提供位置透明性的路由和寻址服务控制服务寻址和命名的管理功能至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）支持至少一种可以广泛使用的传输协议	支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等
服务交互
一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。

请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：

URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。
SOAP/HTTP 支持请求-响应（Request-Response）通信规范。
HTTP 传输协议被广泛地使用。
SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能：

目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。
虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

服务质量和服务级别功能。
高级 SOA 概念，例如服务编排、目录、转换等等。
按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

本文链接

关于RUP(统一软件开发过程)

2010-04-07T08:19:00Z

RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。
　　一、六大经验
　　1、迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程都可以执行版本结束，可以鼓舞开发人员。
　　2、管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。
　　3、基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
　　4、可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。
　　5、验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
　　6、控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
　　二、统一软件开发过程RUP的二维开发模型
　　RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑 (Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物 (Artifact)、工作者(Worker)和工作流(Workflow)。如图1：
　　三、统一软件开发过程RUP核心概念
　　RUP中定义了一些核心概念，如下图：
　　角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。
　　活动：是一个有明确目的的独立工作单元。
　　工件：是活动生成、创建或修改的一段信息。
　　四、统一软件开发过程RUP裁剪
　　RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。RUP裁剪可以分为以下几步：
　　1) 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。
　　2) 确定每个工作流需要哪些制品。
　　3) 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。
　　4) 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。
　　5) 规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。
　　五、开发过程中的各个阶段和里程碑
　　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段 (Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
　　1．初始阶段
　　初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。
　　2．细化阶段
　　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
　　3．构造阶段
　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
　　4．交付阶段
　　交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
　　六、统一软件开发过程RUP的核心工作流(Core Workflows)
　　RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
　　1．商业建模(Business Modeling)
　　商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
　　2．需求(Requirements)
　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
　　3．分析和设计(Analysis & Design)
　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
　　4．实现(Implementation)
　　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
　　5．测试(Test)
　　测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
　　6．部署(Deployment)
　　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
　　7．配置和变更管理(Configuration & Change Management)
　　配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
　　8．项目管理(Project Management)
　　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
　　9．环境(Environment)
　　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
　　七、RUP的迭代开发模式
　　RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期（见图2）。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。
　　一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目（见图3）。
　　图3 RUP的迭代模型
　　与传统的瀑布模型相比较，迭代过程具有以下优点：
　　降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
　　降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
　　加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
　　由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
　　八、统一软件开发过程RUP的十大要素
　　
　　1. 开发前景
　　2. 达成计划
　　3. 标识和减小风险
　　4. 分配和跟踪任务。。
　　5. 检查商业理由
　　6. 设计组件构架
　　7. 对产品进行增量式的构建和测试
　　8. 验证和评价结果
　　9. 管理和控制变化
　　10. 提供用户支持
　　让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。
　　1. 开发一个前景
　　有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相关。最后，由于前景构成了“项目是什么？”和“为什么要进行这个项目？”，所以可以把前景作为验证将来决策的方式之一。对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题： ? 关键术语是什么？（词汇表） ? 我们尝试解决的问题是什么？（问题陈述） ? 涉众是谁？用户是谁？他们各自的需求是什么？ ? 产品的特性是什么？ ? 功能性需求是什么？（ＵｓｅＣａｓｅｓ） ? 非功能性需求是什么？ ? 设计约束是什么？
　　2. 达成计划
　　“产品的质量只会和产品的计划一样好。” (2) 在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原文：process components）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。
　　在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说：“plan什么也不是，planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。
　　3. 标识和减小风险
　　RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。
　　4. 分配和跟踪任务
　　有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在 RUP中，定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必要，更新应该被发布。（原文：updates should be issued as necessary。）这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：While the period may vary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。
　　5. 检查商业理由
　　商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由，并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即 return on investment)。商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理由，计算实际的花费、预计的回报，决定项目是否继续进行。
　　6. 设计组件构架
　　在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么？他们又是怎样结合在一起的？ RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。
　　7. 对产品进行增量式的构建和测试
　　在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经有了一个可用于评估的构架原型；如有必要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素（原文：essential process element）的关键。
　　8. 验证和评价结果
　　顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：The sooner you fall behind, the more time you will have to catch up.）
　　9. 管理和控制变化
　　RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时的交付合格的产品。用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。
　　10. 提供用户支持
　　在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即Bill of Materials）清楚地记录应该和产品一起交付哪些材料。关于需求有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。” 刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：and the requirements just flow naturally.）。也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。
　　九、总结
　　RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足： RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和 OOSP等其他软件过程的相关内容对RUP进行补充和完善。

本文链接

博客园_yunhuasheng's blog

主数据管理和实施

最常见的13种主数据管理（MDM）词汇和定义

构建一个主数据管理(MDM)的解决方案

MDM 介绍二 主数据管理(MDM)的成熟度

MDM 介绍 一

主数据管理（MDM）的七个最佳实践

如何用正确的方法来写出质量好的软件的75条体会

ESB——企业服务总线没有神话

ESB企业服务总线

关于RUP(统一软件开发过程)

MDM 介绍二主数据管理(MDM)的成熟度

MDM 介绍一