第五章、技术平台建设
数字中台是基于云原生、大数据、人工智能等新一代技术打造的共享服务平台。业务中台和数据中台建设带来了更高的架构设计要求、更高的既能要求和更全面的系统特性要求，由此促使企业同时搭建与之相匹配的技术平台，以支撑业务中台和数据中台更好地发展。
本章从技术平台定义展开，阐述技术平台的价值，并简要介绍技术平台整体的架构和功能组成，最后总结应该如何构建技术平台，即策略和方法论。
5.1 什么事技术平台
技术平台为底层基座平台，是支撑业务中台和数据中台发展的基石。
5.1.1 技术平台的定义
==技术平台是基于云原生架构体系打造的服务企业数字中间建设的全景化平台基座==。提提供研发服务、大前端、网关、多云适配、混合云管理及开放平台等多个领域的技术能力和工具集，为企业数智化转型提效赋能。
1.技术平台不等同于技术中台
技术平台是一个平台体系，它包含能够支持业务中台、数据中台及其上层业务系统和应用开发、运行等的整套工具及环境。因此，技术平台既是用于生产业务中台、数据中台和应用系统的工具集，范围覆盖敏捷开发流程管理、测试管理、DevOps流水线、大前端开发等，又为中台和应用系统提供良好的运行环境及监控管理。而根据目前业界的提法，技术中台局限于提供常见的互联网技术中间件服务，包含消息队列、分布式换成，他只涉及数据中台的运行环境，并且只是运行环境的一部分。可见，技术平台比技术中台覆盖范围更广，含义更深远，是能更好地支撑业务中台和数据中台发展的工具平台体系。；因此，我们将技术平台而不是技术中台，作为数字中台的一个重要组成部分。
2.技术平台没有统一标准
企业需要利用先进且多样的技术构建各类能力中心和中台体系。因此需要根据企业业务属性需求，采用不同技术栈、不同的软件系统及不同的规范和标准，为中台建设相应的技术平台。技术平台涉及的范围很广，他即可以看做一个工具集，也可以看做一套整体技术解决方案。技术平台强调资源的整合和能力的沉淀，进而提升建设中台的效率。因此，技术平台的构建需要根据中台的建设要求来选择，提供技术赋能；同时，技术平台的构建也需要组织层面架构调整的配合，否则技术平台的支撑力会显得薄弱很多。因此对于不同企业，技术平台的建设标准是不一致的，也不能一致。
3.技术平台是中台支撑基座
技术的核心价值是什么？在数智化转型过程中，企业需要解决的是业务复杂度的问题，而良好得技术能够带来的最直接效果是提效、降本。不同业务方向的最终交付物所需要的技术体系是不同的。无论是业务中台还是数据中台的建设，都必须依赖对应的技术体系以及相关的技术工具进行支撑。技术平台看也看做整个企业中台建设的底层基座，稳定先进的基座非常有助于上层业务数据应用的快速搭建。从价值体现上来讲，数字中台建设采用的技术是对业务及数据整合治理的理解和实现，可以看做传递价值的桥梁。技术平台提供的是广而全且先进的工具和流程，无论什么团队和角色成员都能方便的使用技术平台，进而支撑整个企业中台的建设。
5.1.2 技术平台的7大价值
技术平台作为支撑数据中台建设的基座，它到底给企业带来什么价值？技术平台通过体系化的工具链，协同研发各角色，进行需求全生命周期跟踪，提供低代码开发平台、全面构建等能力，实现多维度应用管理（见下图），从而规范研发过程，加速软件生产，全面提升研发效率，助力企业数智化转型。
1.体系化工具链
技术平台包含多个基础底层子系统，这些子系统所采用的技术工具的集合可以看做一个大资源池，里面集中了各种各样的技术工具和零散系统。技术平台根据业务场景或支撑体系要求，集成软件研发生成各环节上的工具，串联研发流程，避免割裂式研发，是的数字中台的规划、开发、部署、测试、运营监控成为一个有机整体，从而打造研发的高速通路，构建体系化、规范化、层次化的工具链，助力企业业务快速创新。由此，基于统一的技术平台，参与数字中台建设的各角色能够快速找到所需工具并无门槛使用。
2.全角色协同
无论是业务中台能力中心的维护，还是上层应用的构建，都需要一个团队共同配合来推动协同。一个完整的团队包含多种角色的人员，如项目经理、业务架构师、后端开发、大前端开发、大数据开发等。每一种角色的人员有自身特质和侧重关注的领域，采用适用于各角色相关的工具可以帮助他们提升工作效率。技术平台通过整体拉通，让所有角色人员协同，在统一平台上进行相应角色的业务操作，辅以即时通信、消息告警、邮件、周期报表等方法，并允许查阅协同的工作内容和任务进程，从而提高团队成员的协作效率，降低团队管理成本，优化业务流程，提升整体效率，加速数字中台建设。
3.需求全生命周期跟踪
需求通常可以分为非功能类需求和功能类需求。哪些需求是真实需求？哪些需求是合理需求？需求在每个阶段的进展是怎样的？需求的完成度如何？诸如此类的答疑会伴随整个项目迭代推进过程。技术平台将宏观的业务设计分解为微观的需求问题，以需求为核心，跟踪需求收集，将需求分解为史诗和用户故事。需求最终会经过需求申请、评审、创建、任务分配、分支开发、冲刺迭代、部署验证、发布上线、需求验收等一系列的需求进度跟踪功能，形成需求闭环（见下图）。
通过跟踪与回溯，了解需求的实时状态，明确业务可开展的时间节点，进一步提升业务可见性，以确保合理、正确的需求在中台敏捷落地，保障业务需求转化为商业价值。
4.低代码开发
业务的不断变更和创新带来的是需求的不断增多，开发人员面临的交付压力也越来越大。传统的开发方式需要开发人员编写大量的代码，这样不仅开发周期很长，而且会产生大量重复代码，软件质量差、开发效率低。引入数据驱动式的开发，构建元数据编程引擎，辅以可视化组件，可以实现编码过程的自动化。结合创新性的代码数据化开发理念，即将开发产物作为数据看待，从而将原来的代码脚本等转换为可任意存储且可追溯的数据，再结合组件化、微前端、可视化的页面编辑、无服务器的开发调试，将代码开发转换为创造性设计，随时创建新的页面和应用，从而大大提升开发效率，更好地支撑业务创意快速落地。
5.全平台构建
技术是在不断发展和演进的。企业原有系统有的采用较早期的技术，虽旧但稳定，而最近建设的新系统则可能采用当下最新的技术体系来构建。因此对于研发团队来说，技术很可能是百花齐放的。技术平台打通了不同架构、不同语言、不同平台、不同技术栈的持续构建流程，支持丰富的应用构建模式。比如使用前端统一框架，适配多端应用；使用微服务统一框架，适配多种微服务实现机制。通过统一的平台，解决企业多团队、多技术栈以及各种复杂技术场景的归一问题，降低多平台研发、调试的成本，实现多平台尤其是不同云服务厂商的切换和迁移能力，支撑企业应用多样化演进。
6.应用生态完整
技术平台提供以应用为核心的视角，围绕应用来拓展功能，见如下图，包含应用制品管理、应用分类管理、应用运行
态多运行时管理和应用生命周期管理等。应用制品管理从细到粗，包含代码、软件包和镜像，以多个维度的制品形态提供服务。应用分类管理提供自建、共享以及标准第三方等类型应用，为企业研发人员提供多样化选择，帮助团队快速构建目标应用。围绕应用完整的生命周期，提供快捷可视化操作，方便研发、测试及运维人员对应进行全方位的状态跟踪。同时提供主机、Docker和Kubernetes的多种应用部署运行方式，也为企业在数智化转型中的平滑过渡提供了更多的选择，在保证业务稳定的同时助力创新。
7.多维度数据度量
技术平台提供独立的数据运营监控模块，从项目过程、开发过程、测试过程、运行情况等多个维度和视角展现数字中台开发的进展和最终运行情况。数据是过程度量，有了数据支撑，研发过程才可以持续改进，不断提效，并且所有环节的信息可追溯；数据是指引，有了明确的数据指标，软件架构设计会更灵活、更健壮；数据也是结果，每一个数据报表的呈现，从不同维度展现研发的结果，为决策提供指导。
5.2 技术平台的架构设计与组成
5.2.1 技术平台概览
技术平台作为加速企业中台建设的利器，应该由多种多样的技术体系组合而成。从技术平台分层来看，从底层技术指导应用层系统，包含多云适配层、研发服务层、网关和大前端（见下图）。
研发服务平台再分研发协作平台、低代码开发平台、移动开发平台、数据开发平台和运维监管平台，覆盖了双中台建设过程可能涉及的业务、数据、开发、测试、运维、运营及协同等领域。大前端统一了PC、App、H5、小程序等前端的开发。技术平台所集成的体系化的工具集从不同的维度和领域助力企业数智化转型。
5.2.2 研发协作平台
企业在进行数字化应用建设的过程中，是以团队和项目交付的方式推动系统平台建设的。将所有相关人员协同统一起来，并通过工具化的手段辅助应用的开发、测试和上线，这是企业技术团队需要思考的平台建设策略之一。构建研发协作平台是条解决之道，能有效提升软件系统的协同研发效率，辅助项目的快速交付。
研发协作平台可以利用云原生的架构理念，以分层建设的方式构建。从上往下，研发协作平台可以划分为业务功能层、基础服务层、基础组件层和基础资源层，见下图。
从研发业务场景考虑，他会覆盖软件生产的全流程领域，建议归类抽象出敏捷过程管理、项目应用管理、开发测试部署管理等细分功能模块。采用微服务的架构模式推进平台建设，有助于上层研发业务功能的快速扩展和构建，因此在基础服务层，可以使用包括注册中心在内的相关基础服务，构建权限中心这样的能力中心。同时，为了保证平台系统的运行，也需要相关的基础组件，如数据库、消息队列等。再者，为应用部署提供环境支撑还需要基础资源层的支撑。
对于应用软件的生产流程（见下图）而言，业务核心主流程包含敏捷过程管理、开发流水线管理、部署流水线管理及测试管理四部分。
此外，作为一个平台，研发协作平台还应当有平台本身的一些通用管理模块，因此下文将从平台管理、敏捷过程管理、开发管理、部署管理、测试管理五个主要领域模块，介绍研发协作平台的具体功能和建设实践。
1.平台管理
研发协作平台需要提供一个平台管理的功能子模块，来对基础信息进行设置和管控，如提供用户角色权限管理、消息通知设置等功能。另外，对于运行应用系统的物理资源、开发过程中的产物等也需要进行统一管控。因此，这个平台也应当包含主机资源管理、集群管理、镜像管理、代码仓库管理等功能模块。此外，平台管理部分还可以提供一些相对独立的、层次更高的扩展功能，例如第三方渠道对接、中间件市场、脏数据清理等模块。通过这些扩展功能来扩大平台功能的可用覆盖范围，完善并提升平台的能力布局。
2.敏捷过程管理
软件研发是要给包括设计、开发、测试、部署等的长流程，因此系统提供相应的功能来帮助团队更好地管理研发流程。在研发过程中，可用使用知识管理模块为研发团队提供方便的项目协作和资料内容管理，集中管理产品内容、共享信息以及各类过程文档。此外，为了快速高效地推进项目的开发交付，可建设敏捷过程管理功能子模块，用于管理项目的需求、计划和执行过程，通过协同不同角色的人员，对项目进行敏捷化管控和过程展示。
3.开发流水线
开发过程作为研发流程的核心，涉及的问题有很多，例如应用如何管理、代码如何管理、分支标记如何管理、代码质量如何管理、应用如何构建等。因此研发协作平台需要整合一个开发流水线的子功能模块，提供应用管理、代码仓库管理、分支策略管理、代码质量管理、持续集成管理等功能，将开发的整个阶段通过可视化操作串联起来，提高管控效率。开发人员可在开发控制态查看全局情况，并可使用快捷入口可视化地对代码进行相关操作。平台内置持续集成引擎，通过界面可以查看不同分支的持续集成过程和最终结果，如具体分布的阶段、错误提示、用时统计等。
4.部署流水线
开发人员完成本地开发调试后，需要将应用包部署到相关的开发环境去自验。之后测试人员将应用包部署到测试环境，进行更为全面的功能测试。这个过程会涉及不同环境的创建和管理，包括将包部署到特定的环境、部署后升级、出现问题后重新部署等操作。因此研发协作平台需要有一个单独的部署流水线功能子模块，该子模块重点关注环境管理和持续交付领域。环境管理支持自定义创建环境，并自动生成一条环境流水线，可以拖拽调整环境顺序，同时支持对主机环境进行端口的预分配划分，避免应用主机模式部署因端口冲突而失败。持续交付部分则重点关注应用部署和实例管理，通过按步骤且可视化的提示，支持灵活的应用部署和流水线操作。此外，还需提供全局的实例视图，方便使用者清晰的查看整体项目应用运行情况。实例作为应用的实际运行载体，除了创建，还需要其他生命周期操作的支持，如停止、重新部署、升级、回滚等。另外，在线日志的集成也会方便开发测试运维人员及时掌握应用实例的运行状态，准确定位实例的异常。
5.测试管理
研发协作平台在带来开发侧高效协同的同时，也应当提供敏捷的测试管理功能。可视化的测试用例管理、测试大纲管理、测试计划和执行管理等子模块，可以有效提高软件测试的效率和质量，规范测试人员测试流程，提高测试的灵活性，从而减少测试工作量和实际上，最终让测试跟上开发生命周期的步伐。此外，除了部分手工用例外，还需要提供更智能的自动化测试，例如接口自动化、Mock服务、数据银行、UI自动化等细分功能。自动化的研发协作平台，可大大减少测试人员的重复手工操作，从而提升整体测试效率，全面保障系统质量。
5.2.3 低代码开发平台
为了减轻开发人员的压力，提升交付效率及应用标准化程度、技术平台会采用对应的工具集平台来支撑开发侧的创新和提效。前文提到，技术平台提供的一个很重要的价值是低代码开发，这个价值是由低代码开发平台来承载和实现的。低代码开发平台旨在让使用人员只需要开发很少的代码甚至不用开发就能生成业务所需要的页面或应用系统。它加快了开发过程，统一了页面标准，减少了人为误差，且自动化程度高，上手成本低，可复用程度高。它还可以扩大从事开发的人员范围，不再限于专业的开发人员，相关的业务人员也可以上手按需调整业务系统。 那么如何实现编程过程自动化呢？在大前端整合的基础框架上，抽取数据模型、表单、API等的描述信息即元数据，提供组件库、组件可拖拽等能力，聚合元数据，自动生成代码和界面。此外，开发人员可以在应用初始化阶段，利用平台提供的一套可扩展的代码模板框架快速构建代码工程。 在开发过程中，前后端经常会出现所提供的数据模型与所需的数据模型不一致、导致双方联调的工作量大大增加的情况。因此，可以在前后端请求和响应之间增加一个前后端数据模型映射器（Request-Response Model Mapping，R2M2）。通过数据模型映射的方式，让前后端数据根据需要动态转换，无需在前端或后端更改逻辑代码。数据模型映射可以将接口的字段和数据接口转成前端需要的格式，也可以将前端产生的数据转化为后端接口需要的格式。通过这种方式，前后端无须接触即可完成联调工作，不用再频繁地沟通到底要用什么样的数据结构和字段名。通过一个简单的映射即可让前后端开发解耦，为开发和测试人员提供优雅的服务。 低代码开发平台还有一个重要的价值点是可视化，它能帮助开发人员简单快捷的生成页面。页面引擎将前端的开发工作分解为若干功能块，形成组件库，再基于一种以矩阵编码的协同体系形成统一的样式风格主题。开发者只需根据需求，组合拼装并配置出页面，并将所产生的页面数据交由渲染引擎渲染，即可得到效果页面，所见即所得。可视化的开发方式大大降低了开发成本，让业务类应用无需投入大量人力进行开发和维护，而且代码标准化使得开发人员可随时变更需求页面形态，及时对应所支撑业务的变化。
5.2.4 移动开发平台
企业数智化建设会引发强烈的移动端应用建设需求。无线流量的不断增加，在为企业业务带来增长的同时，也提高了对应用开发人员的要求。作为中台整体支撑基座的技术平台，也需要提供移动开发相关的技术体系平台来整体管控移动应用的开发，这个平台可以称为==移动开发平台==。移动开发平台需要包含移动开发套件及相关研发支撑体系，涉及开发框架及组件体系，依托研发协作平台，支撑移动应用研发生命周期流程管理，助力移动端的研发效率提升，规范移动应用的产出流程。
移动开发套件是移动开发平台的核心，它涵盖框架层、组件层、安全加固层、代码层等模块，利用统一的前端技术栈体系，打通H5、小程序、App等移动端应用的开发。移动端系统同样需有研发协同体系来保障应用的快速交付上线，依托于研发协作平台提供的能力，规范移动应用产出物、标准化构建过程、管理测试真机，以此提升整体研发效率。由于移动应用的特殊性，研发协作体系还应当包含发布渠道管理、热更新、证书管理、运营分析等相对特殊的功能模块。
除了基础的技术架构以及对应的研发协同体系之外，移动开发平台还可以通过内置丰富的组件来加速业务类需求的快速实现和适配，例如标准开源框架，UI控件、路由、媒体、图表等通用开发组件，分享、推送、支付等功能集成组件，以及商品详情、购物车等业务类组件等。
5.2.5 数据开发平台
在数据中台发展的早期，数据中台的建设主要是通过编写大量的ETL和SQL脚本以及代码进行开发，而数据模型则通过文档的方式记录。这带来了诸多问题，比如可维护性差、无法响应业务的变化、文档和实际的代码很那保持一致、数据中台建设的成果很难直观呈现等，而且还需要专业的大数据研发工程师参与其中，人力成本居高不下。
为了解决以上问题，我们尝试了使用一些开源的或商业的大数据研发工具。不过，这样虽然解决了一些问题，但是又带来了新的问题。
1.工具间互不兼容、打通难
建设数据中台的目的是基于OneData理念将企业的所有数据统一存储、统一管理、统一使用，然而现有工具偏向于解决特定领域的问题，需要多种工具组合使用，但工具的开放性不够，无法互通。
2.工具与企业原有的系统兼容难
企业在建设数据中台前一般都已进行过数据方面的建设，大多有一套或多套数据仓库平台。“我们的大数据集群有一定的规模，我们也投入了很多的费用，因此我们希望在现有集群的基础上进行，而不是重新开发一套。”很多企业在第一次与我们交流时，多会提出类似的诉求。已有的数据研发工具一般只支持特定的大数据环境，所以无法很好的兼容企业原有的系统。
3.工具难以扩展
这些工具无法满足数据中台面对的所有业务场景，因此往往需要对工具本身进行扩展。但在扩展过程中，由于工具没有很好的屏蔽底层多种多样的大数据技术和开发语言，导致拓展困难。
基于以上考虑，能更好的助力数据中台建设的开发平台架构应当如图所示：
打造统一的数据研发门户
首先构建统一的数据研发门户，包含数据开发IDE、数据资产管理、数据服务以及一些工具，如标签工厂、ID-Mapping、自助分析等。建设统一的上层应用平台，看似解决的是代码和开发方式问题，但其实最重要的是解决了前文提到的“各类数据工具打通难”的问题，将数据的存储、开发、加工、使用都集中在统一的平台上。数据开发平台形成统一的数据研发门户，进行一站式的数据开发和流程编辑，大大简化了数据开发人员的工作，也无须关心底层的引擎和组件的使用。
构建组件接入层
数据中台需要丰富多样的 存储引擎、计算框架、组件或中间件作为底层的计算存储层。这一层经常会有版本更新或者衍生发行版本的变动。下层的变动会导致上层应用的代码随之修改，并且进行大量的兼容性和稳定性测试。因此，在底层的计算存储层之上加入组件接入层，可带来亮点好处。
- 环境适配：当底层组件层的版本发生变化时，只需要在组件接入层进行适配修改即可，上层的应用不需要进行任何的代码修改。这里解决前文提到的“与企业原有系统兼容难”的问题。
- 简化研发工具平台与底层引擎之间的关系：上层的研发工具平台不再需要各自直接调用众多底层的组件，将原来多对多的调用关系变为多对一和一对多，大大降低了系统的复杂性。由此，上层的工具平台开发者和工具平台的使用者只需关注提供的具体功能和对应的业务逻辑即可，难点问题交由组件接入层统一处理。这也回答了“如何解决工具难以扩展”的问题。
5.2.6运维监管平台
应用软件的生产是一个过程，并且是有时间要求的，他需要多维度的数据以及相关的配套设施来保障，比如物理资源的使用情况、应用开发的过程情况、微服务间的调用关系等。因此技术平台需要建立一套针对此类需求的运维监管平台，聚焦在底层监控、应用开发监控、日志管理及报表展示等功能范畴。
运维监控平台提供基础设施监控，包括实时监控主机与容器集群节点CPU、内存、磁盘及网络等基础性能指标，还可以提供自定义的告警设置，预警资源风险。同时针对微服务应用开发提供应用调用链路监控，业务代码无侵入。采用收集器度量数据，并对数据进行分析和聚合，最终存储统一管理。支持从多个来源、以多种格式收集数据，最终将结果可视化。此外，运维监管平台还可以提供微服务监控，对平台本身运行的微服务组件，通过底层系统进行数据采集汇总后在界面上展示运行情况。
一方面，应用运行会产生大量的运行日志，运维监控平台可以通过集成开源的分布式日志采集方案，对平台日志、应用运行日志进行统一的收集管理和查看。另一方面，可以通过多维度的报表展示研发过程数据，并支撑研发过程的不断改进。根据研发管理流程业务的不同要求，可以将报表集合分为敏捷、DevOps、测试等多种类型。
5.2.7多云适配
随着云服务的发展，将数据中台与云计算融合，成为越来越多企业的选择。数字中台在开发、测试、生产等不同阶段会有很多不同的需求，比如开发时使用本地搭建的开源环境，生产时使用公有云服务等。无论企业在不同阶段使用不同运行环境是基于更好地性能、更低的成本还是更高的可靠性考虑，数字中台都需要一套与具体环境无关的环境抽象层。这就需要在技术平台建设时，在底层引入对应的适配机制，降低数字中台在复杂云环境中的部署成本，实现无缝切换运行环境，而无须更改业务代码。
那么这个环境抽象层应该包含哪些内容呢？结合服务众多行业头部客户的实践经验，我们发现有以下常见的内容。
- 微服务框架，比如开源的Spring Cloud、Dubbo、阿里云的EDAS、华为云的ServiceComb等。
- 中间件服务，比如服务注册发现机制、应用配置、消息队列、对象存储、定时调度、搜索、分布式锁、缓存等。
- 大数据运行环境。
在此基础上建设多云适配层，隔离具体能力提供者与业务代码，即便于企业根据自身的技术特点和运行环境要求灵活地选择，也方便后期升级和维护。
5.2.8 网关
中间建设时会贯彻分布式架构理念，原本单一的系统拆分成众多独立的微服务。当中台外部的应用访问中台时，都会遇到这样的情况：中台系统要判断他们的权限；如何传输协议不一致，需要转换协议；如果调用水平扩展的服务，需要做负载均衡；一旦请求流量超出系统承受的范围，需要进行限流；业务流量进来以后，如何更合理地被导到合适的服务中；等等。
因此，微服务之后的中台系统需要统一的出入口，这就是网关。网关作为中台与外界的联通门户，很好的解决了调用、路由、协议适配及统一接入的问题。网关将对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本，建设客户端与服务的耦合，服务可以独立发展。网管系统一般包含的功能模块有认证、鉴权、安全防护、流量管控、缓存、服务路由、协议转换、服务编排、熔断、灰度发布、监控报警等。有了网关只有，所有外部请求通过入口统一管控，并对外部和内部进行了隔离，保障了中台服务的安全性。
5.3技术平台构建策略
在技术平台构建时，会遇到很多具体的困难，需要采取一定的策略，设定一些技术平台搭建的原则。
5.3.1 困难与挑战
技术平台因涉及的范围很广，在整个平台的构建中会遇到非常多的挑战，比如工具种类多、需要解决的问题点分散等。如何将独立的小系统、小平台整合串联在一起是第一个挑战。每一个流程都有一个或多个工具可以满足业务发展要求，具体选择哪一个或哪几个则是另一个挑战。中台的建设离不开技术平台的支撑，而业务中台和数据中台都有具体的应用场景，因此对于技术平台整合工具链的选择，需要根据中台建设的需要，结合众多的行业经验和实践来确定。此外技术平台怎样才能更好地助力企业数智化转型，从哪些方面提升应用系统生产的效率，如何提升，这些都是在开始构建技术平台时就需要充分调研和考虑的，因为他们会影响到整体平台架构的设计。
5.3.2技术平台设计原则
一个具备市场竞争力和可持续发展的技术平台，应对是基于文件的架构搭建的，能灵活支撑业务的发展，而不会随着业务需求的变更发生很大的变动。在遵循传统软件设计原则的前提下，我们总结了一些技术平台设计原则，包括通用性、先进性、易用性和可扩展性等。
1.通用性
数字中台服务于各行各业，如新零售、地产、汽车、文旅、大健康等行业。每个行业有其独特的专业性，应用软件的某些业务功能也是其他行业所不具备的。但是作为辅助建设数智化转型的中台系统的体系化工具平台，技术平台需要从各行业中提取出共性，而忽略各行业的个性或将其以可挂载的方式建设。因此，在构建技术平台时，首先要遵循的原则是通用性。适配覆盖全景的研发技术场景，支撑更广泛的业务使用场景，满足不同类型企业的研发团队的要求，这些是考虑技术平台的关键指标。
2.先进性
在设计架构的时候，技术平台应当采用较为先进和流行的软件工程方法，选择能够满足业务支撑需求的较为流行的技术体系。先进且流行的技术，通常也是经过时间的检验和多方验证的，是能够支持业务不断发展的，是成熟的。技术平台的设计之初就应当遵循先进性的原则。例如，采用云原生架构构建的平台体系可以有效提高对资源的利用率，并能与生产出来的中台系统更好的融合，提高整体软件研发的效能，从而为采用最新技术的中台体系提供更好的衔接和服务。我们有时会看到，业务系统本身的架构与时俱进，但与之配套的技术平台却相对落后，导致技术平台的理念跟不上业务系统的理念，从而无法与业务系统更好的配合。
3.可扩展性
市场千变万化，企业业务会随着时代的发展变得越来越复杂，这就要求技术平台也能够不断进步和扩展，适应和支持企业的业务创新和快速变更。因此，技术平台还需要考虑可扩展性。可扩展性值得是技术架构稳定，平台应用之间低耦合、高内聚，可以对平台本身的需求进行较为快速的响应。例如微服务化的架构、分布式框架、分布式消息队列、分布式存储等技术的使用，都能够使技术平台具备良好的可扩展性。
4.易用性
技术平台因覆盖面较大，涉及技术较多，对于使用者来说存在一定门槛。因此，平台是否好用、是否方便、是否操作简单，即易用性，是非常重要的设计原则之一。例如，采用可视化界面，友好、直观、形象的展现具体的功能模块，有通俗易懂的指导步骤，操作顺畅不卡顿等，都是易用性的良好表现。站在不同角色使用者的角度考虑需求，设计平台产品功能，以用户为中心，并且通过不断收集多方反馈，这样才能构建出具备高易用性的技术平台。
5.3.3 技术平台规划演进
我们在过去4年服务企业数智化转型的过程中，实践和摸索了技术平台构建和演进路线。从支撑小规模的内部研发团队，到支撑数百人的产品开发和项目交付团队，再到服务于各行业头部企业的中台建设，我们在不同阶段所采用的技术平台是在发展变化的。从最初的脚本化工具，到搭建简单的开源系统支撑项目交付，到中期初步体系化的分领域构建研发服务平台，到现在构建统一的技术平台体系支撑内部协同和外部交付，并将其作为软件定义中台的一个组成部分，主键形成业务和数据中台为核心、以技术平台为基座的完善的数字商业新基建。
5.4技术平台构建方法论
针对企业如何构建自己的技术平台，我们总结出来四步法：选型确认具体方向和技术，划分领域边界来定义支撑范畴，平台化集成，由数据来支撑整个技术平台建设。
5.4.1 选型
选型是整个技术平台建设的根基，他确定了平台的发展方向。技术平台图作为辅助企业数智化建设的平台，为了满足不断变更的业务场景需求，需要结合当前科技发展的趋势，选择最合理的技术体系。
选型需要考虑技术满足度、业务属性要求和成本来确认最终的技术体系。基础技术选型包括开发技术栈选择（如前后端开发语言）、开发框架选择（如微服务框架）、技术架构选择及技术中间件选择（如数据库、消息队列、通信方式等）。考核指标包括可靠性、性能、跨平台、多语言、迁移成本等要求。业务属性有行业规范、开源或商业、特殊安全规范等。此外，技术选型也要考虑团队成员的接受度和学习成本。这样，通过多方面的拉通，经过权衡，从候选的工具集合技术栈中选择适合企业技术平台建设的技术体系。
5.4.2 边界确认
企业在进行中台建设的时候，从业务到数据，从底层IaaS到上层应用Saas，涉及的技术多且杂，将技术归纳为若干个集中的技术业务集合，有助于在构建技术平台的时候，避免零散且无重心，避免建设重复的技术功能模块。因此，技术平台建设的边界也需要重视。边界确认包括确认平台的领域划分、定义平台所涉及的实施领域对象以及子系统的对接要求和规范等。
可以从不同的角度和方向来划分边界，用不同的角色来定义系统。有了边界就有了范围，继而有了建设的目标。确认单一子系统的功能模块，系统内的逐步推进实现，系统外的交互接口，同时也要确认子系统内的输入输出关系。此外，每个划分功能边界后的系统都应该是一个可以独立部署和运行的系统。例如，将管控研发过程的流程类功能模块归纳为研发协作平台，将提升开发效率相关的功能归纳为低代码平台，将侧重于大数据领域的功能独立成为数据开发平台，适配多种云环境的能力衍生出多云适配，而统一入口则衍生出网关等。
5.4.3 平台化集成
有了边界之后，就需要将各个相对独立的子系统整合为统一的平台。平台化是所有应用系统的发展方向，特别是技术平台。平台化的推进过程一定要注重差异化与通用化的平衡，从平台的开放性、移植能力、安全能力、伸缩能力及交互能力等特性全方位考量。对于零散独立的工具子系统，如代码仓库、镜像仓库等，通过构建一个包含统一用户权限管理系统的平台，可以将这些工具子系统串联在一起，进而流程化管理研发过程，告别数据孤岛，推进协同共建。并且，将分散的技术系统整合为统一的技术平台，会发挥1+1>2的综合效应，能更好的支撑上层企业业务中台和数据中台的建设。
5.4.4 数据化支撑
数据通常作为精细化运营的核心被广泛应用，也是构建技术平台时及其重要的方法论依据之一，无论是在研发过程的管控、项目推进的实施还是交付结果的论证等方面，数据都是依据，都是关键。正确合理的数据有助于企业对研发过程的改进和提效。
我们认为数据化支撑应该包含与数据相关的功能和数据评价部分，基于此，技术平台应对建设报表管理、集成设施监控、日志数据分析等与数据相关的数据模块，而数据评价部分则可以包含平台内置的组件种类、组件数量、平台高可用度、提效百分比等度量指标。有了这样的数据化支撑，技术平台的发展也就有了更有利的抓手，从而使技术平台能够得到更好的建设和完善。