对于绝大多数企业来说，企业的信息化建设是随着企业业务的发展不断推进的，而随着企业业务的复杂化和多元化，对于信息化系统的要求也越来越高，对于信息化建设的整体架构、集成整合、数据治理、安全管控的要求也在不断提升，而集成底座就是从企业信息化建设的角度出发，搭建统一、标准、柔性、可复用、可扩展的IT架构，解决企业信息化建设过程中缺乏整体规划、集成整合难度大、安全管控不到位等问题。
集成底座主要包括IDM统一认证平台、MDM基础数据平台、ESB企业服务总线三个产品，产品之间相互支撑，同时对外提供数据和服务。对于企业而言，集成底座更多的是提供一套系统解决方案，奠定企业IT基础，所以在实施集成底座项目时，要立足长远，要充分考虑企业未来的信息化发展趋势。
1总体说明
集成底座主要包括三个产品：IDM统一认证平台、MDM基础数据平台、ESB企业服务总线，其中IDM平台基于5A管控体系实现统一用户、统一认证、统一授权、统一审计、统一应用管控等安全管控；MDM通过支持组织、岗位、人员等主数据的同步分发，实现主数据的标准化，实现全生命周期的主数据管理；ESB作为集成通道，通过API管理将业务系统接口注册、代理到ESB平台，并通过平台实现集中监控、认证、限流、报警等功能，在满足IDM、MDM以及上下游系统的集成管理的同时实现服务接口的集中化管理。
1.1集成架构
集成底座方案的集成主要是基于IDM和MDM作为数据的集中维护平台，通过ESB进行服务API的管理，构建集成通道，从而实现IDM、MDM以及上下游系统的打通。由业务系统作为基础数据的源头，这些基础数据通过ESB同步至MDM平台进行统一管理，保证基础数据的准确性、唯一性、完整性；MDM将组织、人员等基础数据分发至IDM生成对应认证账号信息，用于支持统一认证等业务；整个集成过程中，ESB作为服务总线负责对各个系统的接口和服务进行注册和管理，同时构建系统数据对接的集成流程。
1.2业务场景
集成的业务场景集成主要是基于IDM和MDM的数据同步分发，其中包括业务系统到MDM的主数据同步，主数据到下游系统的下发（包括下发IDM），以及IDM下发账号到下游系统等。
1.主数据同步：
1)源头推送数据（或者推送查询标识）至ESB的集成流程；
2)ESB集成获取源头数据（或者通过查询标识从源头查询数据）后，在集成流程内部调用MDM的接口，将数据写入MDM，同时生成任务和日志，并回写源头系统；
3)ESB集成流程调用MDM的自动提交接口将任务提交至MDM的BPM工作流中，BPM工作流调用MDM接口实现数据向下游系统的分发。
2.主数据分发：
1)主数据分发采用推送的方式，在MDM的BPM工作流中触发推送；
2)下游系统需要提供数据接收接口，在MDM中配置该接口，并在MDM的BPM工作流中调用MDM的分发接口（分发接口内部调用下游系统接收接口）实现数据分发；
3)下游系统接收数据后，接口内部进行系统写入，完成后调用MDM的日志回写接口进行数据回写操作。
3.账号分发：
1)账号分发主要是通过IDM将登录用户信息分发至下游系统，实现各系统的统一认证和单点登录；
2)IDM账号分发主要是将IDM的账号信息通过任务的形式分发下游系统，和MDM的分发方式类似；
3)在账号信息进入IDM平台，可以手动或自动的方式生成分发任务，再通过IDM内置的BPM工作流进行自动提交；
4)在BPM工作流内调用IDM的分发接口将数据推送至下游系统的数据接收接口中，而下游系统的数据接收接口则配置在IDM平台的应用管理中；
5)下游系统完成数据写入后调用IDM的日志回写接口进行数据回写操作。
1.3实施模式
集成底座主要包括IDM、MDM和ESB三款核心产品，通过反复的内部演练以及实际项目的磨练，目前集成底座已经逐渐形成了一套标准的实施规范，包括主数据的规划、数据同步分发、账号管理、统一认证、API管理等，所以目前集成底座更多采用产品 + 培训的交付模式，即我们提供产品以及基于云平台的环境部署、产品安装，同时提供对于各个产品、集成方案、接口开发的培训，由伙伴或者客户方来完成具体的实施和建设工作，而在实施过程中，我们进行远程或现场的技术支持和指导。
集成底座的实施模式需要轻实施、重培训，强调伙伴或客户在实施过程中的参与，这样做的好处在于：
1.降低项目参与度，减轻工作量，能将项目团队投入到更多的项目中，满足公司发展需要；
2.内部团队有更多的机会参与项目、了解业务，了解产品和方案在实际项目中的应用，有利于团队的建设和成员能力的培养；
3.培训伙伴或客户熟悉产品的使用和项目实施，发挥伙伴方、客户方的优势，加快项目实施交付的效率；
4.伙伴或客户掌握到产品和方案的精髓后，更有意愿去推动更多的同类项目，从而提供更多的商机，提高产品出货量。
1.4实施流程
集成底座项目的实施流程也是遵循规范的项目实施流程，包括需求调研、环境部署、实施交付、上线验收、后期运维等阶段，但是和实施类项目不同，集成底座采用产品 + 培训的模式，所以更多的工作是需要交付伙伴或客户方完成的，项目团队更多的是起到辅助的作用。
1.需求调研：由项目团队和实施方共同完成，项目团队提供调研模板、调研大纲、调研思路，双方共同参与明确项目需求和范围，实施方了解业务、需求，同时熟悉产品的使用，便于后续的实施交付；项目团队提供资料协助实施方完成调研，同时搭建测试环境，培训实施方了解产品的使用，同时项目团队需要在调研过程中了解客户的业务，强化业务能力，也为后续项目提供借鉴；
2.环境部署：环境部署一般由项目团队或内部运维团队负责，集成底座采用云平台的部署方案，提供一键部署脚本和对应的文档，可以实现快速部署；在实际项目中一般会部署两套环境：一套测试环境采用非高可用部署，在前期调研阶段部署，用于给客户演示、调研需求和产品使用培训；一套生产环境，一般在正式实施时部署，采用高可用部署，搭建开发、测试、生产环境，满足后续项目开发、测试、生产运行需要；
3.实施交付：集成底座主要采用产品 + 培训的实施模式，实施交付的主体一般是合作伙伴或客户的信息化团队，项目团队主要是根据前期调研的需求协助输出对应的标准规范、蓝图资料，以及在实施过程中提供产品培训、技术指导、方案支持等，一般提供远程支持，但可以根据实际情况，提供短期的现场支持；
4.上线验收：上线、验收和实施一样，主体也是合作伙伴或客户的信息化团队，项目团队以支持、辅助为主，协助实施方输出上线文档、上线流程、回滚策略等，协助实施方完成项目的整体上线试运行，以及最终的项目验收；
5.后期运维：一般运维工作内部会移交运维团队，具体运维工作由伙伴或客户方进行，内部运维团队只负责解决一些产品使用、功能上的问题，同时针对伙伴或客户方经常出现的问题进行技术指导和培训，协助伙伴或客户更加深入地掌握产品和方案，以促进后续更多的合作。
对于集成底座项目，在实施交付过程中，在不同的时间节点，需要交付的文档清单如下：
2需求调研
需求调研是项目实施的第一项工作，也是非常重要的工作，由于前期项目团队、伙伴、客户、业务厂商的熟悉程度不够，缺乏足够的信任，往往需要一段时间的磨合，所以在这个阶段需要经常沟通、相互交流、加强合作、达成共识，为项目的成功奠定基础。
集成底座项目又是一个跨组织、跨业务、跨系统的项目，所以调研时往往需要对客户的需求、实际的业务、系统的情况、厂商的配合等各个层面进行调研，更需要项目团队掌握沟通技巧、了解产品方案、熟练调研流程。在沟通过程中，需要不断输出集成底座的实施方案，引导客户、厂商按照集成底座的标准模式进行实施，降低实施交付的难度，以达到项目的快速交付。
2.1主数据管理
主数据的调研一般需要从项目的整体规划和实际业务出发，梳理主数据的具体范围，以及每一类主数据的编码、属性、来源、目标、集成等内容，具体内容可以包括：
1.项目规划：项目规划一般在客户进行项目立项时就会明确，规划具体的建设内容和建设范围，但是在项目开始实施时，实施团队需要和客户反复进行讨论，一方面是对具体实施范围进行确定，确定哪些做，哪些不做；二是对客户进行引导，使项目的实施过程遵循集成底座的标准流程，便于后期实施交付和上线验收的推进；
2.核心业务：调研过程中要充分了解客户的核心业务，梳理业务时结合现有的业务系统进行分析，明确业务运行过程中可能涉及的主数据，同时在梳理过程中也要对客户的业务进行分析整理，积累对业务的认知和理解，为后续项目的实施、售前、产品开发等提供借鉴；
3.类别明确：明确本期项目需要建设的主数据类别，如果单纯从集成底座的角度，一般只需要建设组织、岗位、人员等人事相关基础数据，但是为了满足客户的业务需要，同时加强集成底座的实际应用场景，可以考虑根据实际业务建设一些重要的主数据，支撑业务的同时也为后续深度主数据治理和数据中台建设奠定基础；
4.编码规则：主数据的编码规则一般有两种情况：一是由源头系统提供，MDM平台直接引用源头系统编码，二是在MDM平台配置编码规则，在数据同步到MDM平台时自动生成。第一种直接复用源头系统，MDM无需进行处理，但是需要源头系统保证编码规则的唯一性、准确性；第二种MDM需要配置编码规则，可以保证唯一性、准确性，但是在同步时需要将编码回写源头系统，二者各有优势，在实际项目中可以根据实际需要灵活选择；
5.属性定义：MDM支持元数据管理，可以根据实际需要配置各类主数据的属性信息，一般属性的定义需要包括以下内容：源头系统包括的属性，并且需要分发到下游系统，实现多系统共享；在实际业务运转过程中需要维护使用的属性；
6.参考数据：参考数据由业务系统提供，一般由源头系统提供，MDM平台参考进行配置，同时由于各个系统参考数据的定义是不同的，所以涉及数据下发时，需要明确下游系统的参考数据定义方式，并在MDM平台进行关联配置；
7.校验规则：主要是针对不同的属性配置校验方式，如非空、数字、唯一、长度等，主要是为了保证主数据的规范性、完整性，降低人工维护时产生的异常数据；
8.来源系统：针对每一类主数据需要明确主数据的权威来源，来源于哪个系统的哪个模块，是否能采用推、拉的方式进行数据推送，是否可以配合进行扩展等；
9.目标系统：针对不同的主数据需要明确都有哪些业务系统进行接收，是否有对应的接收接口，是否能够配合进行扩展，接收时需要接收哪些元数据等；
10.集成方式：集成底座的数据集成支持推、拉、定时等方式，但是为了保证数据的及时性，绝大多数采用推、拉的方式，一般会涉及上下游系统的改造，包括上游系统的实时推送，以及下游系统的数据接收接口等，在调研时要明确具体的集成方式以及相关数据接口。
2.2.统一认证
统一认证主要是基于集成底座的IDM平台实现的，平台提供了CAS、OAuth、接口三种认证方式，满足不同场景、不同系统的对接需求。在前期调研过程中，要明确需要对接统一认证的系统有哪些，分别采用哪种开发语言、技术架构，针对不同的语言、架构提供认证方式，具体实施时由系统方根据认证标准自行配置处理。
IDM平台支持密码集成，包括密码同步、密码分发，但是在实际项目中，不建议进行密码集成，一方面进行密码传输的过程中，容易造成密码泄露，增大安全风险；另一方面实现统一认证之后，登录直接采用统一认证，使用IDM的密码进行认证，不需要保持业务系统和IDM的密码一致。
2.3统一API
集成底座的统一API主要是基于ESB的API管理功能实现，在ESB的SMC管理控制台中将各个业务系统的接口统一注册进来，支持Web、Rest、Http等不同类型的服务接口，注册后的接口可以在应用集成中调用，也能通过代理的方式提供给其他系统。
在项目调研过程中，主要需要明确接入的业务系统有哪些，除了集成底座内部的接口注册以及应用集成配置外，是否有其他系统需要进行接口注册，是否有单据集成、凭证集成等集成需求，是否需要在ESB进行接口统一管理。
对于注册在ESB中的接口，需要明确对于接口安全、数据安全、数据加密、安全认证、异常报警等机制的需求，根据需要进行标准制定，以便后续实施过程中进行对接。
2.4标准规范
集成底座的标准规范主要包括以下内容：
1.主数据数据规范：根据制定的主数据范围，制定每类主数据的相关数据标准，包括编码、属性、参考数据等；
2.主数据管理规范：从组织管理角度出发，针对主数据的管理组织、管理角色、管理人员、维护流程等内容制定统一的标准要求；
3.主数据集成规范：基于制定的主数据范围、属性，以及对接的上下游系统，制定数据集成标准，包括推送、拉取的方式，触发的机制，推送的内容和业务系统等；
4.主数据清洗规范：主要针对MDM平台的数据初始化，对于现在系统中已有的历史数据，在初始化同步到主数据平台时，如何进行清洗、合并、标准化处理；
对于主数据的数据规范、管理规范、集成规范、清洗规范，一般会合并到同一个主数据标准规范文档中。
5.MDM主数据平台接口说明：MDM平台的接口标准文档，该文档会根据MDM平台的开发和升级进行升级。
6.IDM身份管理平台接口说明：IDM平台的接口标准文档，该文档会根据IDM平台的开发和升级进行升级。
7.ESB企业服务总线服务标准：ESB平台的标准说明文档，主要针对ESB平台服务接口的开发标准、协议支持等。
8.IDM统一认证对接标准：主要针对IDM统一认证相关的内容说明，包括统一用户说明，CAS、OAuth、接口认证说明，以及统一密码实现说明等，参考如下。
3环境部署
集成底座采用云平台的部署方式，在实际项目中一般由内部实施团队或内部运维团队负责部署安装，一般会建议部署两套环境，一套是基于3台服务器的非高可用环境，一般用于前期调研时对客户进行产品演示、样例说明，以及针对伙伴或客户信息化团队的培训工作；另一套环境是在调研后期或蓝图确认后部署的正式环境，采用至少5台服务器的高可用环境，内部至少部署开发、测试、生产三个环境，以保证在实施过程中的可以进行产品的配置、环境的搭建。
3.1K8S部署
集成底座采用云平台部署方案，现在K8S的云平台部署已经构建了一键部署脚本，可以通过脚本实现快速部署，同时支持离线部署，即使在内网环境下，也可以完成环境部署工作。并且针对3台非高可用和5台高可用提供不同的部署脚本，可以满足不同使用场景的需要。
3.2产品部署
集成底座除了包括IDM、MDM、ESB三款核心产品外，还有UMC云管理平台，主要用于配置和管理K8S集群，以及集群内部的环境、容器、产品、组件等配置与部署，以及外部Nginx的接入配置等。对于UMC上容器、产品的部署，也支持通过一键部署脚本进行操作，并提供由对应的部署文档。
3.3 安全策略
集成底座一般面对企业级客户，并且涉及了企业的核心数据，为了保证数据的安全性，需要从网络、服务器、产品等多个层面保证系统的安全性，主要包括：
1.在准备服务器时建议搭建堡垒机，通过堡垒机跳转访问真实服务器，提高服务器安全性；
2.服务器防火墙只开放内部服务器之间的IP互通，不开放外部IP和端口的访问，对于部署外部Nginx的服务器，根据部署的环境对应开放相应的端口；
3.对于Redis、数据库、产品等相关密码都需要采用复杂密码，并且保证密码是不一样的，避免密码泄露的可能。
3.4环境测试
环境部署后需要对环境进行整体测试，包括产品功能、服务接口、集成流程，要根据实际业务需求对功能、压力进行测试，保证功能可用的同时，也要保证服务器的稳定性和并发压力。主要测试内容：
1.IDM、MDM、ESB的各个功能模块，包括页面显示、数据管理、配置功能等，以及ESB设计器的连接，工程、服务、流程的开发部署等；
2.IDM、MDM、ESB的相关服务接口，包括数据提供、数据接收、任务处理、token认证等；
3.IDM认证压力测试：对IDM的CAS、OAuth、接口认证进行压力测试，基于JMeter模拟实际业务场景进行并发压力和稳定性测试，主要测试高并发的认证登录以及低并发长时间的稳定性（8-10小时）；
4.MDM数据接口测试：针对主数据的同步、分发、查询接口进行压力测试，主要测试低并发、大数据量的情况；
5.测试后需要输出对应的测试报告。
4实施交付
集成底座采用产品 + 培训的实施模式，项目的实施交付主体为伙伴或客户信息化团队，而内部项目团队主要负责产品培训和技术支持，以远程支持为主，根据具体项目进度和实际情况，可以短期进行现场技术支持，但实施的主体也是伙伴方，而非项目团队。
对于集成底座项目，主要的实施内容包括：
1.数据集成：以主数据为主，进行MDM和上下游系统之间的主数据同步分发，其中包括了IDM的数据同步，以及IDM用户数据的分发；
2.应用集成：以IDM为主，实现各个系统的统一认证，搭建统一认证中心；
3.服务集成：以ESB为主，将各个系统的服务接口注册到ESB平台进行统一管理。
4.1产品培训
产品培训是集成底座项目中非常重要的部分，由于采用的产品 + 培训的模式，所以需要通过培训让实施方充分了解产品的特性、使用场景，以及对于不同的业务场景，应该如何通过产品配置进行实现。培训的主要内容需要包括：
1.集成底座的整体集成架构、数据架构、集成方式等；
2.集成底座和上下游系统集成时，集成的内容、集成的方式，提供的数据；
3.MDM平台数据管理维护的方式，主数据模型的配置过程，包括模型定义、属性定义、编码规则、校验规则，以及同步分发过程中的系统注册、分发范围、接口调用等；
4.IDM平台组织、岗位、用户的管理维护方式，扩展字段的配置，密码策略的配置，统一认证的配置，同步分发的相关接口说明等。
4.2数据集成
主要是主数据的同步分发，包括：
1.从源头系统主数据同步MDM平台；
2.MDM平台数据下发下游业务系统；
3.MDM平台组织、岗位、人员数据下发IDM；
4.IDM用户数据下发需要接入统一认证的系统，保证账号一致。
数据集成的过程中，需要主推标准的集成方案，集成底座内部的数据集成可以直接复用预置的相关服务样例，和上下游系统对接时直接根据蓝图阶段制定的标准规范。推荐实施方式：
1.主数据同步采用推送模式，由源头系统触发推送数据，通过ESB开发应用集成流程实现源头系统到MDM平台的数据写入；
2.MDM平台下发由下游系统提供接收接口，集成底座提供标准的数据格式，采用MDM的推送（或推拉）模式将数据（或任务标识）发送给下游系统；
3.IDM的账号下发和MDM一样，也是由下游系统提供接收接口，IDM采用推送（或推拉）模式将数据（或任务标识）发送给下游系统。
4.3应用集成
应用集成主要是基于IDM平台构建统一认证体系，打通系统访问的壁垒，IDM平台提供CAS、OAuth、接口认证三种认证方式，业务系统根据自身系统情况自行选择，实施团队协助提供配置样例和说明文档。
一般集成底座的IDM实施会以统一用户、统一认证、统一审计、统一应用管控这4A为主，而统一应用管控是在IDM平台配置各个系统信息，统一审计是对数据的统计、分析和监控，所以统一用户、统一认证往往是集成底座项目中最多的内容。
1.统一用户：IDM用户分发下游系统，保证IDM和下游系统登录账号的一致性，建议采用推送模式，IDM提供标准的参数格式，下游系统提供数据接收接口，由IDM平台推送用户数据至下游系统；
2.统一认证：基于IDM的标准认证方式，以下游系统为主配置统一认证。
4.4服务集成
以ESB的API管理为主，对业务系统的服务接口进行API注册、API管理、API代理、安全策略、监控预警等内容。
1.配置ESB应用集成时进行服务接口的引用；
2.其他系统集成时调用ESB代理接口，通过ESB进行日志记录、监控、预警等；
3.推荐对接的接口都注册到ESB中，基于ESB进行监听和管控；
4.对于IDM、MDM、ESB等内部使用的接口，全部注册到ESB中通过应用集成调用；如果支持外部系统调用，则需要对接口进行代理；
5.如果项目中存在单据集成、凭证集成的业务集成需求，则需要通过ESB进行API的注册、代理，业务系统直接调用代理接口；
6.如果需要保证数据安全性，建议采用数据加密、token认证等机制进行接口控制。
5上线验收
上线验收和实施交付一样，也是以伙伴方的实施团队为主进行推动，内部项目团队在这过程中进行辅助支持，以保证项目的顺利上线，包括上线前期的资料准备，风险评估，以及上线后的运行监控、产品问题修复等。
5.1上线准备
在上线前需要对上线需要做的工作提前进行梳理，形成上线文档，明确上线时间、上线步骤、初始化数据、接口切换等内容，由于集成底座项目涉及各个系统的集成与切换，所以需要和客户方提前约定时间，在不影响客户业务运行的情况下进行升级切换，特别是存在历史系统的升级的情况。
1.上线时间：上线的开始、结束时间，数据准备、系统切换的时间节点，需要明确到具体时间点；
2.上线步骤：上线的具体流程，包括数据服务器准备、环境部署、数据初始化准备、系统切换、接口切换等，并且需要明确每个节点的人员和时间节点；
3.初始化数据：包括IDM、MDM的数据初始化以及业务系统的数据初始化，明确数据初始化的时间节点和负责人；
4.接口切换：原有系统的接口切换步骤，包括旧接口的停用以及新接口的启用时间节点等。
5.2风险预案
风险预案主要是针对上线过程中可能出现的问题进行提前预估，并制定解决策略，如果上线过程中出现问题，可以按照风险预案进行紧急补救。一般情况下由于集成底座采用云平台部署，可以直接通过资源同步快速部署生产环境，同时在上线前也会在测试环境进行模拟验证，所以大多数情况下上线会比较顺利。
但是由于集成底座会和各个业务系统集成，所以可能出现业务系统交互异常的情况，所以针对各种可能出现的问题要提前进行预估，如上线后无法实现统一认证拦截，统一认证成功后无法跳转业务系统，数据集成时出现数据同步失败，ESB代理的API无法调用等问题，针对每一个可能的问题都需要制定问题排查处理的策略，保证可以快速进行问题定位和处理。同时也需要做好最坏的准备，即上线回滚，如果问题比较严重，上线后无法满足业务使用，则需要制定回滚策略，回滚到上线前的状态。
5.3 上线监控
在项目上线后需要实施团队实时关注项目运行情况，包括IDM认证情况、MDM/IDM的数据同步分发情况，ESB服务接口的调用情况，同时也需要对服务器的运行情况进行监控，保证各个产品可以稳定运行。
上线监控阶段不仅需要实施团队进行监控，客户方的信息部门以及业务人员也要参与其中，主要是确认业务运行是否顺利，是否存在数据异常等问题，并且对过程中的问题进行记录和反馈，实施团队及时跟进处理，保证项目的顺利上线，以便于推动后续的验收。
5.4验收推进
在上线运行稳定之后，实施团队需要开始整理项目验收资料推动项目验收，根据项目的具体情况，验收资料也会有所区别，对于集成底座项目，一般至少要包括以下内容：
1.服务器信息，环境部署清单，部署文档和资料，相关登录账号和密码；
2.需求说明书、设计说明书、使用手册、操作手册、标准规范、集成说明等蓝图资料；
3.产品测试报告、安全报告等测试相关资料；
4.项目运维文档、常见问题处理等运维相关资料。
项目的验收推送也是以实施方为主，内部项目团队主要是提供相关资料模板和说明，协助实施方出具相关验收资料。
6后期运维
后期运维主要包括两部分内容：一是由伙伴的实施/运维团队进行的日常运维，一是由内部运维团队进行的远程技术支持，主要处理实际业务中出现的产品级问题。
6.1运维团队
由于集成底座采用产品 + 培训的方式，所以运维会以伙伴方为主，伙伴方根据实际情况建立运维团队进行日常的维护，协助客户进行问题定位与处理，主要处理客户实际业务中出现的使用问题、相关流程的优化、配置的优化等，以及客户业务变更时出现的流程调整等内容。
内部运维团队主要负责解决产品级问题，如果产品在实际运行过程中，如果出现产品BUG，内部运维团队需要协助进行问题定位与处理，同时对于产品在使用过程中也要对伙伴和客户进行指导，加强使用方对产品的深度理解。同时为了保证集成底座的应用效果，一般在项目上线后也会进行一些产品升级，这些升级工作需要内部运维团队提供升级说明，协助伙伴方完成升级。
6.2运维流程
针对项目中运维工作，需要制定标准的运维规范和流程，包括客户使用产品的方式，使用过程中的注意事项，出现问题时反馈的渠道、反馈的方式，运维团队问题处理的步骤、时间节点等。运维的目的不仅仅是消除问题，同时也是向客户输出知识的过程，通过指导、培训，使客户能充分掌握产品的使用，甚至能自行进行问题的定位与处理。
6.3运维手册
项目运维手册在项目上线后就需要整理，在验收前需要提供给客户，以便在项目运维过程中能及时进行问题处理，将出现问题时对业务的影响降低到最小。不同于蓝图、产品等相关文件，运维手册是一个需要不断完善的文档，在实际运维过程中，需要根据日常的运维情况将新出现的问题及时整理到运维手册中，一方面可以帮助客户更好的掌握产品的使用和问题的处理，同时也能为后续接手运维的人员可以更快速地熟悉工作。
6.4知识传递
知识传递是一个持续的过程，而且是贯穿在整个项目周期的，从前期调研甚至更早开始，就需要向客户、伙伴进行知识传递，包括对方案的理解、产品的应用、业务的融合、管理的方式等，需要让客户方、伙伴方了解方案、认可方案，才能保证在实施过程中更好地推动项目的实施过程。
项目实施、培训、运维的过程也是知识输出的过程，需要不断向使用方进行知识的输出，使各方对集成底座有更深入的理解，并能够在实际业务过程中发现集成底座的优势，加强对集成底座的使用效率，使集成底座能真正发挥出在企业IT规划中积极作用，促进企业信息化的发展。
集成底座方案以IDM、MDM、ESB产品为核心，为企业信息化建设搭建基础的、统一的、标准的、可复用的、易扩展的IT框架，在复用企业IT资产的同时也为后续的信息系统建设奠定基础。而作为标准的集成方案，目前集成底座已经满足了在不同项目中快速复用的条件，所以后续集成底座类项目大多数会采用产品 + 培训的模式，由伙伴方进行具体的实施落地，所以内部团队要熟悉集成底座的每一个环节，对于产品、流程、业务、场景等内容要由充分的理解，并把这些知识不断传递出去，提高伙伴方对集成底座的理解和认知，也能保证后续有更多集成底座类的项目顺利上线。
