软件工程师罗小东，多年平台架构设计和落地经验，这里主要是针对于中台化项目交付与传统项目交付的一些心得体会。

理念

Supercell游戏开发公司内部有一套技术平台，旨在提供支持Supercell开发的多款游戏的共享工具、技术和基础设施。这个中台包括了各种组件和服务，如玩家账户系统、社交网络功能、统计分析工具、虚拟货币交易系统等等，这些工具和服务都可以在Supercell开发的不同游戏之间进行共享和复用。

让Supercell游戏开发团队更加专注于开发游戏本身，而无需重新开发已经存在的功能或迎合特定游戏的需求。同时，这也能够促进Supercell内的知识共享和协作，并且降低整体开发成本和风险，这也是中台架构的由来。

概述

在过去几年中，我们一直专注于中台架构和项目的开发。尤其是在处理中小型项目方面，我们积累了丰富的经验。以下是一个典型案例的分析，我们将从实践中总结出的心得和经验与大家分享。

在2023年的第一季度，团队完成了一个约为百万级的大数据项目。我们采用中台产品和ISV（业务组）合作伙伴的方式进行交付。相对于传统项目，这种模式在交付和团队优化方面有明显的不同。只是说感觉相对于网上各种理论来说，各种概念的解释来说，原来初衷的理念更加符合，而我想要的也是这个模式，而不是网络上被各种名词和概念所淹没的中台模式，有时候会把一些简单的事情说得太过于玄乎，而没有体现初衷。

起初听到芬兰SuperCell模式时，原本觉得有这个可能，但是过程当中的体会没那么深，对外交流的时候，各种底气还是来自于一些材料，但是当真正自己在用SuperCell模式(也就是中台)的时候，你会发现，这个结构在一定的程度上确实将团队的结构还有能力进行了优化处理，而且整个流程过程会更加顺利，这里主要从几个角度进行阐述：

• 项目中的中台组织结构是怎么样的；
• 过程怎么分工处理同时做好前端的支撑；
• 过程的一些常见问题和规避操作；

不同于大厂的中台交付模式，但团队和经验不同，因此我们只针对中小型项目进行说明，我有我思。

过程

在过程中，做了很多的职责分离，这里针对于原来的数字中台运营方式来进行，角度阐述也是从这个运营思路。

项目中的中台组织结构是怎么样的

传统项目的组织结构会一个项目从各个层级跟到尾，可能管理团队多个方面，而这里略有不同。

在这个大数据项目里面，我们的组织结构基本上对项目经理的职责还有中台人员的职责进行了调整（这里不提商务）。

在传统或者一般的项目里面，项目经验对接的职责和范围可能会比较大，在项目组里面人员权限也比较大，调动的人员可能从下层的开发和底层的技术人员可能都会涉及，而在中台的组织结构里面，我们把项目结构进行了两层拆分，分成了中台层和项目层，而项目经验对接的只是每层的负责人。另一个是项目的实施过程也进行了拆分，分多个阶段，一个是中台的产品交付和业务需求的实施交付，还有另一个是中台后期的支撑。

感觉这个过程好像跟一般的项目过程，比如甲方乙方等实施交付区别不大，我第一感觉也是如此，但是实际并不是。

这个阶段之间的分隔，在传统项目交付里面并没有那么明确，而且人员意识还有团队意识，过程的沟通，交付产物等，各个角色支持力度等需要更加的明确，怎么说的呢，就是在前期一些培训阶段的时候，问题最多不是技术，反而是这个阶段之间的实施问题。常常会出现，要么就是业务进到中台层里面，要么就是中台层进入到业务里面，类似的情况，往往是缺少阶段处理的意识，这个就会形成一定的交付隐患。

中台层要做的是架构方面和一定范围能力的技术的支持，但是不要介入到业务里面，业务场景最合适的业务层的解决办法，中台需要提供的是平台级的能力，因为中台层要支撑的不仅仅是一个项目，而是多个项目，这个需要在支撑阶段提出明确的支撑能力，哪些有，哪些没有。

业务只需要根据中台的能力来进行场景的规划，如果需要的或者确实没有的而一定需要用到的，或者提交需求到中台即可，而不是等着中台解决业务问题，形成两边的死循环。

在前期的组织结构初期，就做了明确的沟通要求了边界，明确划分哪个阶段参与和明确提出计划和时间。

过程怎么分工处理同时做好前端的支撑

传统项目可能前期有需求还有原型等之类的，或者需求调研之后才会考虑到实施，这里也略有不同。

在数字中台上会带有一部分基础的业务能力，还有一些通用的服务组件，在项目确定开始之后，基本上实施计划和工作就已经开始，另外加上是一些数据类项目，通用的组件更多，而我们要做的是数据输入层，也就是数据调研和采集，这个前期都有一定的模板和样例，在项目开始的前一周，实施的准备条件就已开始部署，交付出第一版本给客户演示的时候，差不多是项目开始后的两三个星期左右，后面就是培训使用。

而这个过程业务端在进行业务的处理的开发，中间加上客户的时间情况等等，这个业务型开发的时间在一个月左右，因为在中台上也包含技术devops，在这个过程都会自动同步到用户测试环境，这个过程时间相对来说，也比较从容，业务团队过程中需要的文档和手册等处理，中台团队会有一些培训，这个培训时间大概是前面的三天左右时间。其它的就是等数据调研这部分的结果，完成之后数据采集到数据中台里面，进一步的分层、计算、接口等获取到指标，输出给业务方，这部分主要是中台的过程中的操作，同步带好业务端的人员怎么使用，带好流程。

这个过程中一个比较大的体会是角色定位和分工上，还有时间点的把控上等都会比较明确，会有一些卡点，但是相对于以前传统项目方式来说，这个会更加明确。

过程有碰到的一个时间是过年时间，在这个时间后，基本上业务演示的第一版本也就出来了，在给领导层做演示，得到一定的认可后，基本上就走验收流程。前后大概是两个月的时间，其它的时间点会有一些运维和管理的操作，这部分在业务上，也在移交到运维层面上，在项目上投入的资源也进一步的减少。

这个过程中的一个比较明确的体会就是时间，时间点上会比较明确和准时，如果说业务组在缺少数据中台产品的支撑和中台团队的支撑，是基本上不可能在这么短的时间出的结果，而中台团队没有前期的积累也基本上不太可能会跟业务组和项目实施等配合得好。甚至在实施过程中，因为业务组一直做的是业务组件（我们把业务组件分开和微服务化），在交付实施过程才发现这个项目是一个比较大的项目，涉及到模块那么多，这也是原来考虑的，业务组要做的是做好业务场景需求就可以，其它的中台层给好支撑点。

另外一个因素是中台和业务组的磨合，初期的项目会有一些磨合，如果这个过程没有做过，可能会消耗一至两周的时间点，这个需要考虑的。

过程的一些常见问题和规避操作

过程一直强调角色和职责，业务组和中台组就做好自己的事情就可以。

在这个过程中，也会有很多的坑点，一些不注意可能也会形成项目后期的问题，类似于技术债，大致列了几个问题：

1. 避免让业务组接触太多的技术概念而忽视业务
   在中台会有很我技术概念和学习层面，这个过程容易使业务组的技术人员深入到技术层面，比如微服务、容器化、主数据、Hive等，它需要的是一个模板和使用说明，而不是研究说明，根据业务场景来进行模板输出就可以，后面根据个人兴趣去学习即可，重点是给出使用案例。比如数据采集，跟业务组人员说“发送到数据总线”可能他们会迷糊一下，但是跟他说“发送到这个API接口”他就立马明白。
2. 实施过程中台文档的产出
   文档材料的产出是过程中特别需要注意和加深的，也是中台组的要求，这里对业务组的要求由项目经理，但是中台组的要求是一定要有文档的产出，这个文档的产出并不是只是一个项目，而是多个项目都有在使用的时候，这些文档和沉淀对中台组来说意义就比较大，实现的输出的意义也比较大，同时对文档有比较严格的要求，格式还有内容等，形成高质量的文档，这部分不论在哪个项目都做了强制性的要求，同时方便后期更新迭代等。
3. 避免两个组之间互相切换和沉入
   中台切入业务，业务切入中台，这个是前期特别容易出现的问题，只需要一个简单的场景，在讨论过程中，如果没有这个意识，就会变成中台组在做业务组件开发的情况出来，或者业务组提要求了，然后中台组根据特定（注意是特定）修改中台组件的情况，后面一种是我们特别容易出现的，而且也特别头大，有些情况下确确实实是中台组加个字段或者加个功能会比较简单，但是这个属性是某业务特有的，实际上这个过程从业务组做维护会更好。比如我们会用电信厂家的接口发送短信，而不会给个单独给某个业务设置接口，除非说这个接口有多行业公共的属性，那再统一集成。

当然，还有周期、工时、支撑、商务等挺多方面，这些主要依赖于过程的团队的情况和管理方式进行处理，这里就不做过多的阐述。

总结

在前期多个中小型项目中，我们建设中台体系的过程虽然有听说中台模式的好处和优势，但是身边比较少成功的案例（除了一些大厂），或者说在使用了并没有发挥出它本身应该有的作用，结合起来发现并没有达到降本增效的层面，反而发现过程更加复杂和麻烦，最后发现可能还没有原来单体应用的简单。

这些以前见到其它陷入的比较多，从自己的心得来说，这些是一个过程点，但是要达到终点，这个需要比较大的，而且长期的团队实战和不断迭代升级过程，上面是在这方面的心得体会，希望可能给一些人参考。

软件工程师罗小东，多年平台架构设计和落地经验，这里从智慧型项目、数字化项目进行数据治理建设的一些经验总结。

概述

针对于中小型团队和当前接触到的大部分项目来说，很少有非常大的数据治理需求，特别是互联网型的PB级数据。在大部分情况下，数据量在TB级或亿级级别较多。相对于PPT级别的方法论，会更加注重于实际运用，为了应对这些场景，我们在以下几个方面进行了考虑和优化：

• 是否真的需要建立一个Hadoop体系的数据仓库
• 针对于中小型客户数据治理需求怎么建设
• 怎么样针对当前的项目进行数据资源管理
• 后期的数据治理和各个数据治理维护怎么做

在真正理解项目需求、精细化管理以及灵活选择数据治理工具和技术的基础上，能够更好地应对不同场景下的数据治理需求。不同项目不同架构，我有我思。

过程建设

许多客户都有数字化建设的需求，但不同的场景需要使用不同的技术方案，在具体的建设过程中，整理的一些思路：

• 首先要充分了解客户的业务场景和需求，从而选择最适合的技术方案。
• 在建设过程中，要注重数据质量和服务，以确保数据的准确性和能力体现。
• 合理规划数据治理流程，包括数据采集、清洗、转换、存储等环节，并通过数据可视化手段展示数据治理效果，提高数据治理成效。
• 对于不同的项目规模和预算成本，选择不同方案，优化算法和调整计算引擎，减少资源和成本。

针对不同的客户场景，规划合理的数据治理流程。

是否真的需要建立一个全套的数据仓库体系

针对于不同的场景，对于数据治理，需要根据具体场景来选择合适的方案

前期的搭建方式

目前在搭建数据治理平台时，开始我们使用的是CDH做为数据仓库底座，通常使用Hadoop体系的数据仓库平台，并按照ODS/DWD/ADS等层级进行划分，通过Kettle/Filebeat/Sqoop等方式抽取数据进行离线计算，使用Hive做为数据仓库，我们的工程师在这块上也有多年的治理经验，计算引擎使用的偏向于Spark，数据建模和维护也是按通用的数据标准处理，这个有前期多个项目里面基本上都是，有一些项目会运行在K8S上。

这个过程消耗的资源较多，而且计算引擎和计算过程比较统一，特别是Spark计算的时候，消耗大量的内存资源。而对于一般中小型项目，或者一般的客户来说，这个资源的建设会成本过高，特别是在数据治理这块并不是要求特别高的时候。

客户数据治理成本高

一些客户可能并不理解数据治理的成本和价值，除了政务型项目或不缺费用的项目，很难落地，没有达到预期的数据运营效果。

比如一个智慧社区项目，在这块上的数据仓库主要存储的数据在几个方面，用户行为、IOT数据采集、还有视频流数据的存储（只存储主键祯数据）,另外就是一些业务系统的数据采集存储，针对于以上数据的分析，与AI结合，提供出API服务能力，在这些数据中，超过一定生命周期的会做清理，最后评估出来10年左右180T存储，而这个过程中，大部分是冷数据。

最后建设使用的方案是云厂家的一体机来进行管理，但是这个成本是极高的，类似于这样的数据场景，遇到的比较多，最后在考虑一个问题，是否需要这么重的数据仓库。

针对于中小型客户数据治理需求怎么建设的

建立一个轻量级的数据场景，以更好地满足不同项目的需求。建设轻量级数据治理平台

建设轻量级数据治理平台，是优化数据管理和维护成本的方法之一。目前大数据套件较多，学习成本较高，对中小型团队而言，这一成本占比较大。因此，需要采取有效措施降低人员培训成本和管理维护成本。

将多个工具整合为轻量级数据中台，使用minio分布式存储、Clickhouse数据仓库、kettle抽取工具和kafka数据总线等技术统一数据治理，适配各类规模的企业需求。在数据清理和转换后，将数据存储到ODS层，非结构化和半结构化数据存储在分布式存储和ES中，并根据生命周期规划定期清理不必要的数据，只保留有价值的数据和流程相关数据。

此外，针对人员培训，设计系统化的培训课程和多种灵活的培训方式，以提高员工的数据管理和分析能力。对于团队管理和维护，可以建立数据治理的文化氛围，鼓励全员参与，同时引入自动化工具和脚本，减少人工操作和管理成本。

通过以上措施，项目可以建设出高效、灵活的数据治理平台，降低人员培训和管理成本，提高数据治理能力和业务价值体现 ，实现项目的业务需求和决策目标。

怎么样针对当前的项目进行数据资源管理

建设通用的数据治理能力组件和平台组件，以便根据具体项目需求进行选择和组合，实现对数据资源的有效管理。

针对当前的项目进行数据资源管理，可以建设一套通用的数据治理能力组件和平台组件。这些组件可用于多种场景下的数据治理工作，如：

• 数据上报服务：供政务、个人、单位等通用型用户使用的通用数据采集上报平台，支持非技术型人员和部门进行数据入仓。
• 数据总线服务：连接数据平台中不同组件和子系统的核心组件，实现数据的快速传输和交换，并统一集成数据主题管理。
• 主数据管理服务：帮助企业确保数据质量、提高业务流程效率，并为数据分析和决策提供支持，促进企业内部数据的标准化、管理和共享。
• 数据集成服务：提供在线设置ETL作业、转换任务的定时运行策略，监控任务的执行情况，查看任务执行日志的功能，强有力地支撑后续的数据开发、数据挖掘。
• 数据开发服务：向数据开发工程师提供拖拉拽控件的方式，设计复杂的工作流有向无环图，挖掘出有商业价值的数据。
• 数据安全网关：提供数据交换、数据共享、数据开放的平台，包含网关接口安全、接口权限认证、黑名单管理、Oauth2接口认证等功能，向组织内各个部门提供支持。

这些数据治理能力组件和平台组件可根据具体项目需求进行选择和组合，实现对数据资源的有效管理，我们采用灵活的数据治理方案，根据项目大小和需求，选择相应的数据治理工具和技术。

在提供工具的同时，针对于业务的个性化要求和业务开发需求，比如报表、大屏、还有数据服务使用等，当前是让ISV团队进行处理，而这个过程由中台团队提供技术支持和培训，而数据治理套件不对客户。

后期的数据治理和各个数据治理维护怎么做

建立一套完善的数据治理流程和规范，包括数据质量控制、数据安全保护、数据持续更新等方面的要求

实现数据治理和各个数据治理维护的目标，包括数据流程标准化、人员技术培训、数据指标采集等。在实际应用过程中，需要根据企业的具体需求和情况，适当调整和优化数据治理策略，以提高数据质量和效率，为项目的发展提供有力支撑。

• 数据流程标准化：通过数据总线服务连接数据平台中的不同组件和子系统，以便实现数据的快速传输和交换，并统一集成数据主题管理。建立标准化的数据流程，包括数据采集、清洗、存储、转换等环节，并确保每个环节都符合相关标准和规范。
• 人员技术培训：利用主数据管理服务对企业内部数据进行标准化、管理和共享，确保数据质量和提高业务流程效率。同时，为各个层次的员工提供有针对性、系统化的培训课程，提高他们的数据管理和分析能力。
• 数据指标采集：使用数据集成服务在线设置ETL作业和转换任务的定时运行策略，监控任务的执行情况和查看任务执行日志的功能。确保多种数据格式和来源的数据经过清洗、转换后能够及时有效地送达组织的数据仓库，并为后续的数据开发和挖掘提供支持。
• 数据治理目标达成：使用数据开发服务向数据开发工程师提供拖拉拽式的控件，设计复杂的工作流图，挖掘出有商业价值的数据，帮助企业实现对数据的全面管控和治理。同时，使用数据安全网关进行数据交换、共享和开放的管理，确保数据的安全性和防止潜在的风险。

同时实现对数据的全面管控和治理，确保数据的质量和安全，提高数据开发和分析的效率和准确性，从而更好地支撑企业的业务需求和决策，提供出数据服务和治理。

总结

数据治理是数字化建设中非常重要的一环。在进行数据治理时，我们需要根据不同的业务场景和需求，选择最适合的数据治理方案，包括选择不同的组件组装和数据存储方式等。对于轻量级数据管理平台和重量级数据管理平台，我们可以针对具体情况进行选择，权衡成本与效益，以满足客户实际需求。在整个数据治理过程中，我们还需要注重客户成本的管理，确保项目的落地和实际效果，并且不断优化数据治理流程，需要积极参与业务需求分析和技术选型，确保数据治理方案符合客户需求和行业标准。

过程考虑不同的场景选择不同的数据治理方案和组件组装，根据实际情况选择轻量级或重量级数据中台，注重客户成本管理和实际效果，以满足客户需求并推动数字中台建设。

以上为在大中小型项目中的数据治理经验输出，提供一些参考。

附录

• 我们使用的数据开发工具是dolphinscheduler进行二次开发整合 ，是一个非常优秀的数据开发工具

软件工程师罗小东，多年平台架构设计和落地经验，以下针对于中小微团队在数字中台的实践管理，主要偏于实操描述。

背景

这里的产品并不是互联网运营的，而是内部研发产品，后期用于项目。

数字中台产品管理，产品线大概有20个，产品工程管理基线是50个左右，自动化任务大概有250+个，当前维护ACP产品的属于微小团队，当前产品线的管理维护人员为6个人，主要偏向于产品功能的优化管理和升级，前端ISV团队的支撑，项目的技术支撑，还有针对于运行的数据治理上的二次开发（比如基于日志分析的安全感触服务），配合商务的输出等。

过程的管理主要是基于过程规范标准化、自动化操作、微服务、容器化管理、数字中台架构、云计算等。

概述

在这个建设过程中，基于原来alinesno-cloud开源项目进行升级优化，这里主要是针对在过程的实践情况，还有团队的使用情况，包括主要使用的技术能力，运维管理，运营管理等，以低成本进行运维，提升团队的能力的竞争力，希望可以给一些在往这块方向的团队一些参考，在这个过程中主要使用的技术场景如下：

• 规划化标准化：工程过程的标准化和规划化，规避掉培训成本，管理成本，学习成本、升级成本的问题，形成统一化，比如在升级只需要调整核心包即可。
• 微服务：工程的划分会提高运行的稳定性，根据场景各个服务可拆分，可组件，规避工程的耦合，还有管理职责分开等，还有微服务的性能还有分布式等能力
• 自动化：主要是人工的解放，还有流程标准化的自动化，规避掉一些低级的人工错误，操作成本等，比如过程的流水化、备份管理、日志清理、数据抽取等。
• 容器化：这里主要是服务的发布管理和部署低成本，还有工程版本的维护，一键部署的管理，运行监控，比如链路跟踪，客户项目发布等。
• 数字中台架构：基础技术组件和数据治理组件的融合，对项目业务上进行数字化解决方案和项目的数据治理、规范处理、还有业务项目开发的管理等。
• 运行监控：这里主要是运维上的预警管理、还有运行状态巡检、应用存活的管理等。

这里阐述主要通过几个方面进行实践阐述，偏向于落地：

• 标准化和规划化的要求，怎么样做到项目和工程架构的统一，怎么样要求落地。
• 基础环境能力的搭建，使用的资源有多少，后期怎么管理。
• 产品的迭代升级管理，还有过程怎么降低产品管理成本。
• 项目交付实施的过程是怎么样的，怎么做项目交付支撑。

以上的所有操作过程基于整个DevOps/GitOps/DataOps架构进行整合，过程形成流水线管理，每个架构师设计有自己的情况，我有我思。

过程实践

这里通过几个阶段过程，将过程有节点进行细化说明，以下为主要维护产品的团队。

标准化和规划化的要求，怎么样做到项目和工程架构的统一，怎么样要求

如果说这个制定过程需要做很多部门、沟通、还有使用过程问题矛盾等，那就规避掉这些。

前几次在其它团队做平台的时候，前期最大的问题，就是沟通和团队人员的提升，这个会花掉很多力气，特别是在意见上几乎很难统一，团队越大，这个问题就越突出，会给培训、还有各种技术思维的输入等，做好前期的准备。但是这个成本在中小团队成本是极高的，而且还有一个问题是人员流失的问题，培养出来了人走了，后来换了一个思路，做这块的只需要一两个高级人员，后期提供出代码生成器和标准文档，发给项目组和开发就行，其它的人员并不需要特别关注。

比如开发人员一定要会使用微服务？一定要会springcloud的么？其实不然，自己并不一定需要学习这个，会写controller，还有查询mybatis编写即可，后面学习中会有遇到，这个过程可以做到无感。

开发人员会主动去查询材料和学习，主动跟被动的区别，效果差异是极大的，后面定义好岗位职责的考核，根据过程做适当的培训，这个过程团队成长更快。

标准化前期部分主要参考社区的流程，还有架构也一样，但是这些不要紧，先有一版本，技术还有能力很快就会沉淀在前期架构的人员上，这个过程会不断的迭代，所以在这块上的选人是很重要，至少能总结和有兴趣，有优化的主动性。在建设出来一版本标准规范之后，将代码做核心公共包的封装，再加上代码生成器，出来即是规范，几乎是可以做到对团队人员的无感知。

这个过程差不多1个月左右。

在前期的框架封装上避免过度封装，这个是新人架构师的一个痛点，会有非常多的idea，但是前期基本上都禁掉了，换成的思路是先出一版简版的，再根据一些项目过程中，了解问题，再进一步的升级封装。

这个过程经历过1个项目就基本上就比较成熟，包括架构人员，具体时间看项目的情况。这个过程会遇到一些问题，也是允许的，这个是之前的培训成本遗留下来导致的，这个时候可以多一些使用培训 ，针对问题来进行统一的培训或者指导处理，过程多与团队沟通解决掉即可。

基础环境能力的搭建，使用的资源有多少，后期怎么管理

这里基础环境搭建分几个部分，一个是devops/gitops/dataops的环境搭建，还有公共服务组件的发布搭建，比如数据治理组件、技术组件、运维组件等。

这也是基于规范标准的要求，比如自动发布管理，这里做成参数型的配置，还有数据抽取组件也一样，做成脚本型和参数型的设计，使用Git统一的管理，主要是为了更好的做好记录，权限，留痕等，结合jenkins整合起来的，包括运维脚本、CICD、数据抽取等，使用人员比较少，所以在这块上的资源压力倒不大。

目前整个环境使用了3台服务器，主要是一台jenkins/技术组件/数据组件，主要的配置如下：

• 自动化服务(Jenkins): 16G内存/8C/250G磁盘
• 技术组件：16G内存/4C/80G磁盘
• 数据治理组件：32G内存/8C/1024G磁盘

这主要是得益于微小团队的产品开发维护，另外我们数据仓库并不一定要求使用Hadoop套件，而且针对项目情况来进行适配选型，所以这并不是很大的压力，而且一些高峰的操作，比如备份和巡检、数据抽取等会在晚上执行。

在实际项目中，会根据项目的情况抽取产品部署，这主要利益于微服务架构，可拆分的能力，将耦合降到最低，比如有些可能需要的数据组件只有一两个，那就部署一两个，做好对应的适配资源即可。以降低项目成本和维护成本，还有客户成本等。

这个过程的管理基本上是写好脚本之后，就根据监控即可，这里集成了钉钉，主要是方便管理，这个任务大概是250多个任务，基本上都是利益于GitOps的理念，这里需要的是它的理念，然后整合起来的，过程主要是针对于Git基线，而不是需要针对于所有，从Git流程的最终结果是钉钉通知，这样以降低学习成本还有规避掉过多的人工操作。

这个的搭建和规范建设，大概是2个星期左右，当然，这主要得益于经验的积累，只需要做调试，如果从零开始，可能需要1-2个月左右考虑会比较合适。

产品的迭代升级管理，还有过程怎么降低产品管理成本

这里类似于运营管理，这里的运营主要是指内部团队的运营，将ISV和其它部门当做客户即可。

这里的组件比较多，针对于微型团队来说，如果没有统一的基础设施和规范是很难的，这里主要是利益于微服务架构和容器化管理，还有中台架构思维。

公共和基础服务已经将大部分非业务逻辑的都做了，也抽取成公共的服务能力，比如日志、登陆、公共权限、前端埋点、数据抽取、监控等，都已经是打成基础的能力，每个服务都是可以一开始就拥有这些能力，也可拔插，主要升级组件内的逻辑，比如集成监控。

当然还有很多。

将公共组件进行沉淀，在各个产品只需要，也只能保留业务部分，而且一定不能过分的建设每个组件的公共部分，这样会导致后期的升级和版本管理的困难，这也是中小微团队的灵活性，就是因为小，在调整的时候，可以统一，每次升级会把需要调整的部分列出来，然后发给对应的组件即可。现在基本上是调整版本号即可，因为公共部分的抽取已经很好了，比如前端，后台，还有ORM层等，基本上业务组件并不需要调整哪些。

另一种是功能的升级，这个过程根据业务调整单独组件即可，小的功能升级会做好接口的兼容，大的单独提供出新的接口，同时加上版本号。在这部分比较担心的是稳定性，所以在工程模块上的划分，也是做了严格的限制，也主要得益于DDD架构思维，但并不是完全照搬，而是根据实际做了调整，取其优势即可，工程模块如下：

这里抽取了一个domain服务组件，这个服务组件一定要资深人员才能处理，其它的非核心逻辑都在gateway和provide模块里面，调用domain工程的写好的逻辑，其它的人员写前端和接口即可。

这么做的原因是为确保服务的稳定性，以前遇到过挺多类似的情况，初级的维护人员和经验不足的碰到和核心服务的逻辑，但是熟悉程度不够，导致了很多不稳定的因素，在这块上是做了很严格的要求限制。

实在不行，就重写接口，但是不会影响到核心逻辑，核心逻辑部分主要是由更高一级的人员来编写维护的，一个是编码的质量，另一个是稳定性，以确保后期的产品的质量。

基于上面的技术思维和管理规范，组件的升级，比如当前的国产库适配、漏洞的升级等基本上是调整核心包的版本号即可，功能的升级也是通过核心和外围接口两个概念进行区别，不需要说再花时间去深入到模块和业务等，调用接口实现。

提交代码之后，就是走刚刚上面提到自动化流程，等钉钉通知和容器监控状态，然后结合界面测试。

项目交付实施的过程是怎么样的，怎么做项目交付支撑

这个是数字中台价值输出体现之一，主要是偏向于跟ISV团队的整合，让ISV团队主要考虑业务逻辑的事情。这里主要提供几个能力：

• 产品使用培训还有技术架构方案支撑
• 过程涉及数字中台产品的技术架构和解决
• 需求的适配的一些功能开发或者问题处理
• 商务上的文档支撑和客户讲解
• ….

通过以上为ISV团队赋能，主要的目标是项目的落地，提升ISV的能力提升，这也是数字中台的价值体现之一。

ISV团队要考虑的是业务，而我们主要的目标是不要让他们深入到技术、还有非业务性的内容上，同时提升出好的工具给他们。

这样更好的进行区分职责边界，这个其实也是个矛盾点。目前是通过代码生成器生成出业务组件，然后在这个组件里面只包含业务，其它非技术的组件交互（比如账号权限）通过Api来进行处理，有哪个API就有哪个能力，以规避掉职责不清的问题。

业务组与整个数字中台进行对接的是Git还有可视化的界面，并不需要它关注太多的东西，业务逻辑提交到Git之后，其它的流水线会自动走下来，然后得到对应的访问链接即可。

而数字中台就使用产品型的交付，根据项目情况进行服务的抽取，其它的商务不做太多的接触，只需要关注数字中台产品体系的内容，一个是沉淀，另一个是项目涉及到的面比较多，避免平台人员沉入到里面，而无法抽出，同时也规避掉ISV团队过度依赖平台人员，为后期的维护考虑。

这里也有一个特别需要注意的项，就是职责角色一定要区分，不能互相深入，比如平台人员做项目的事情，项目人员做平台的事情，这会无形中增大成本和提高项目风险，可能会导致后期的管理混乱，商务和项目上纠结不清，如果项目更多的的，会以提工单的形式来进行反馈，比如需求和问题。

这个过程一般是在项目前期一两个星期会有比较多的沟通，ISV后期和熟悉之后，后面的合适会比较顺利，即使是在ISV新人切入，这个过程成本也会低很多。

总结

数字中台本身是一个很大的概念，但是在过程怎么使用和抽取，还有适配团队，其实并不代表会有一个非常高的成本管理，而是根据团队来进行适配，以体验和获取到云原生时代、新技术的便捷红利，以提升团队的技术能力、竞争能力、还有新的商业模式，在数字化的时代做好准备，以适应当前行业的发展。

以上为在数字中台建设和管理的一些实践，希望可以给一些在往这块方向的团队一些参考。

罗小东，软件架构师，多年平台架构和落地实战经验。在目前行为的发展状态下，数字化并不仅仅是一些大厂家可以做的，自己的一直以来的架构经验里面，中台是中小企业或者团队的新型基础设施，提高团队技术能力和竞争力的利器

概念

数字中台、技术中台和数据中台之间有着密切的关系，它们可以相互补充、整合，协同提高企业的数字化能力。

首先，技术中台是数字中台和数据中台的基础设施，因为技术中台提供了通用的技术组件和服务，使得数字中台和数据中台能够更加快速、高效地进行开发和部署。比如，技术中台提供的标准化接口和服务可以帮助数字中台和数据中台实现应用程序和数据的集成和共享，从而提高企业的运营效率和质量。

其次，数据中台是数字中台的重要组成部分，因为数据中台提供了企业内部和外部数据的采集、存储、加工和分析等功能，为数字中台提供了更加全面、深入的数据支持。数字中台通过整合各类数字资源，加强不同应用之间的协作和集成，从而能够更好地满足企业数字化转型的需要。

数字中台通过技术中台和数据中台提供的基础设施和支持，实现数字化资源的整合、协调和优化，从而为企业带来更多的商业价值。

概述

随着数字化时代的到来，企业必须转型升级才能适应新的商业环境。而数字中台作为未来企业新型基础设施，成为了中小企业提高技术能力和竞争力的一大利器。以技术中台和数字中台为基础，建立针对中小企业的数字中台基础设施，可以为中小团队带来技术能力提升和自动化提升的基础，进而提高团队的技术能力、数字能力、竞争能力等。

数字中台作为未来企业新型基础设施，是推进信创、国家数字化战略以及技术高质量发展的重要手段和支撑。中小企业在数字化转型过程中面临诸多困难和挑战，如缺乏专业的信息化团队和资源、信息孤岛问题、数字化转型成本高等，而数字中台可以为中小企业提供有效的解决方案。

建立针对中小企业的数字中台基础设施，可以帮助企业实现信息化系统的整合和管理，降低信息化系统成本，实现自动化和智能化，提高工作效率和生产效益，提升团队的技术能力、数字能力和竞争能力。同时，数字中台也具有开放、共享、可扩展等特点，为中小企业提供了更加灵活、高效和创新的发展机会。

以下为几个方面进行阐述：

1. 数字中台解决了什么问题？
2. 为什么需要建设数字中台？
3. 数字中台的作用是什么？

以下为主要内容阐述，这里主要针对基础设施来进行阐述，而非业务。

内容阐述

在信创、国家数字化战略以及技术高质量发展的背景下，企业内部存在大量的信息化系统，这些系统数量众多、种类繁多，管理和维护起来非常繁琐。同时，由于不同系统之间缺乏有效的交互和共享，会导致信息孤岛问题，影响企业信息化管理的效率和质量。

通过数字中台的建设，企业可以降低信息化系统的管理成本和维护成本，提高信息化管理的效率和质量，进而为企业的数字化转型提供基础保障。因此，数字中台在信创、国家数字化战略以及技术高质量发展中扮演着一定的角色。

它解决了什么问题？

解决了信息化系统的不协同问题：企业内部存在大量信息化系统，数量众多、种类繁多，管理和维护起来非常困难。数字中台可以将这些系统进行整合，实现信息的统一管理和共享，从而消除信息化系统不协同的问题。

解决了信息孤岛问题，使企业内部信息互相连接：企业内部各个信息系统之间缺乏有效的互通和共享，导致信息孤岛问题的出现，影响信息流通和利用效率。数字中台提供了标准化的接口和数据格式，使得不同的信息系统能够快速、高效地进行数据交换，避免信息孤岛问题的发生。

解决了大量重复工作和人工操作，实现自动化：数字中台可以通过自动化的方式完成大量重复工作和人工操作，提高工作效率和生产效益，同时也可以降低相关成本。

解决了企业在数字化转型过程中的技术难题：数字中台作为新型的基础设施，可以帮助企业实现技术资源的整合和归纳，提高技术服务效率和质量，为企业数字化转型提供坚实基础。

解决了企业数字化转型成本高的问题：数字中台可以整合企业内外部各类数字资源，形成一个开放、共享的数字化生态系统，降低数字化转型的成本，并且提高数字化转型的效率和质量。

为什么中小企业需要数字中台？

中小企业在数字化转型过程中面临着种种困难和挑战，而数字中台的建设可以为中小企业提供有效的解决方案。以下是详细描述：

中小企业常常缺乏专业的信息化团队和资源，数字中台可帮助其提升数字化能力：对于许多中小企业来说，在信息化系统的建设和管理上缺乏专业人才和资源，这使得数字化转型变得更为困难。数字中台作为一种新型的数字化架构，能够帮助中小企业实现信息化系统的整合和管理，并提供数字化服务和技术支持，从而帮助中小企业提升数字化能力。

数字中台提供了开放、共享的数字生态系统，支持企业增强产品创新和服务能力：通过数字中台建设，企业可以将原本分散的数字资源进行整合和共享，形成一个开放、共享的数字化生态系统。这使得企业可以更加高效地进行产品创新和服务开发，提高企业的竞争力。

数字中台实现了信息化系统的整合和管理，降低了企业的信息化系统成本：数字中台可以将企业内部各个信息化系统进行整合和管理，避免了重复投入和维护成本的浪费，从而降低了企业的信息化系统成本。

数字中台实现了自动化，提高了企业的工作效率和生产效益：数字中台可以通过自动化的方式完成大量重复工作和人工操作，提高工作效率和生产效益，同时也可以降低相关成本。

数字中台为中小企业带来了数字化转型的机会，让其更好地适应新的商业环境：数字中台作为一种新型的数字化架构，可以帮助中小企业实现数字化转型，适应新的商业环境。通过数字化转型，中小企业可以拓展市场，提高生产效率，增加收入，提升竞争力，并更好地适应未来的商业发展趋势。

数字中台有什么用？

实现信息互通和共享

数字中台作为一种新型的信息化架构，可以将不同系统的数据存储在一起，实现信息的互通和共享。与传统的信息化架构相比，数字中台能够提供更加灵活、开放的数据交换方式，从而避免了信息孤岛问题的出现。数字中台利用标准化的接口和数据格式，使得不同的信息系统能够快速、高效地进行数据交换，实现信息互通和共享。这样，企业内部各个部门之间就可以更好地协作，避免了信息流通受限、信息利用效率低下等问题。

提高技术能力和竞争力

数字中台可以为企业提供数字化转型所需的技术支持和服务，包括云计算、容器云等多种技术。通过数字中台建设，企业可以更加轻松和便捷地获取到最新的技术服务和解决方案，从而提高企业的技术能力和竞争力。数字中台还能够帮助企业实现数字化转型的目标，推动企业在数字化转型过程中迈出坚实的步伐。

降低成本、提高效率

数字中台可以大幅度降低企业信息化系统的建设和维护成本。在传统的信息化架构下，企业需要投入大量资源来进行信息系统的开发、测试、部署和运维等工作，这些过程繁琐且耗时长，效率较低。而数字中台可以通过标准化的数据交换方式、自动化的流程操作等方式，实现信息化系统的快速开发、部署和运维，从而提高了工作效率和生产效益。

提供创新发展机会

数字中台可以为企业提供开放、共享的数字化生态系统，为企业的创新发展提供坚实的技术支持和服务。数字中台能够帮助企业获取更多的数字资产和资源，同时也能够促进数字技术的创新和应用，推动企业数字化转型的深入发展。数字中台还能够支持企业的新产品开发，优化服务流程，提升用户体验，从而增强企业的竞争力。

支撑企业数字化转型

数字中台是数字化转型过程中的关键要素之一，它能够帮助企业快速响应市场需求，完善数字化转型体系，提升企业竞争力。通过数字中台建设，企业可以实现信息互通、自动化流程、创新发展等多方面的目标，从而推动企业数字化转型的全面发展。数字中台能够为企业提供可靠的技术支持和服务，缩短数字化转型的周期，降低数字化转型的成本，提升企业的数字化能力和竞争力，帮助企业在新的商业环境下实现更高的价值和收益。

企业内部自动化

数字中台实现了自动化和智能化，降低了企业的人工成本，提高了工作效率和生产效益。数字中台通过自动化的工作流程和任务分配，可以实现大量重复工作和人工操作的自动化。数字中台还能够将企业内部多个信息系统进行集成和整合，避免了重复投入和维护成本的浪费。通过数字中台的自动化支持，企业能够更加高效地进行工作，提升生产效益和竞争力。

提高数字化转型效率

数字中台可以快速响应市场需求，提高数字化转型的效率和质量，帮助企业更好地适应新的商业环境。数字中台能够在数字技术、数字服务和数字架构等方面为企业提供强有力的支撑，加速企业数字化转型的进程。数字中台还能够为企业提供完整的数字化转型解决方案，帮助企业快速实现数字化战略和目标。通过数字中台的支持，企业能够更加高效地运营和创新，提升数字化转型的效益和质量。

总结

在目前行为的发展状态下，数字化并不仅仅是一些大厂家可以做的，自己的一直以来的架构经验里面，它是中小企业或者团队的新型基础设施，提高团队技术能力和竞争力的利器，数字中台是未来企业的新型基础设施，对于中小企业而言，建立数字中台基础设施可以为其提供技术能力和自动化提升的基础，进而提高团队的技术能力、数字能力、竞争能力等。

罗小东，软件架构师，多年平台和中台企业建设和落地经验，以下为从工程师角度，第一人称进行阐述，会略带有口语。

背景

阿里走向组织治理的全新阶段——构建‘1+6+N’的组织结构，即在阿里巴巴集团之下，设立阿里云智能、淘宝天猫商业、本地生活、菜鸟、国际数字商业、大文娱等六大业务集团和多家业务公司，会有一些思考。

本文针对的是此类思考做的文字阐述，分以下几个点：

• 思路阐述
• 怎么使用
• 使用要求
• 后期维护

虽然现在很多企业或者团队都已经实践了，自己感觉这个好像并不需要再讨论，这里只做一家之言，我有我思。

思路阐述

中台解决问题的定位不一样，这个概念出来挺多年的，但是见到的解决方案和架构，基本上都是一个套路，一个路数，到目前为止，见到很多解决方案，大部分，很少说见有遇到能讲解或者见到对这块比较有深入表达，或者比较惊艳的理解，这个在很多时候，都是极度模糊的词和边界。

这个表达貌似有点奇怪，如果做过架构的同学会有一个体会，一个架构在另一个地方可以落地，可能换个地方就不行，如果不好理解，再换一个例子，比如软件工程流程，在一般的中小项目基本上很难走通，那套规范，可能还没有开始，项目就线束了，那是不是就否定这套流程，其实不然。

在过程中感受是，关键是否能把这个核心和思路深度消化，然后运用起来。

在前几年讨论过很多回，也在很多团队接触过讨论，在这个过程中的感觉好比别人送给你一个屠龙刀，会使用的人可以扫四方，但是不会使用的，可能会惹火上身，甚至会发现，还不会以前菜刀方便，关键是怎么使用。

怎么使用

我是怎么使用中台的，这里只是一个参考，除是产品型输出打造以外，主要使用在几个方面：

• 我需要快速创建业务应用，解决掉创建应用过程中的问题
• 我需要做数据仓库和挖掘，数据以更好的辅助应用的建设
• 我要运维和监控这套平台，解决应用过多的问题的问题
• 我需要快速跟进行业的发展，提供出更好的解决方案
• 我需要一个稳定可控的平台，来支撑我的解决方案落地

日常使用过程的方式，管中规豹，需要一些团队管理的想像而扩大到团队。

解决掉创建应用过程中的问题

比较不喜欢一上来就提n多好的技术和业务无关的，有个文档告诉1、2、3点，然后就实现这部分就可以，其它的不想关注。

创建业务应用到底有什么问题，怎么就能快速创建业务和应用。

这里定义的业务不是所有的业务，也包含当中的某一个模块或者某一个功能，这主要还是依托微服务架构，首先，在开发过程中，对我来说，最注重的是成本，主要偏向于时间成本，开发成本，维护成本，升级成本等上面：

• 目前行业不断的架构和技术变化，这个过程需要不断的消耗时间
• 每个模块的规范不一样，无法共用一些功能，每个都需要消耗时间去调整
• 非功能性需求不稳定，CURD的常用功能不稳定，在调整这块上一直消耗时间
• 简单和重复的功能每次都需要复制编写，在稳定性上测试也消耗时间
• 运维监控和日志监控这些我需要做监控，在排查问题上消耗时间
• 在交接需要跟别人解释这个怎么集成，主要在非业务解释上也消耗时间
  …….

以上制约了我很多无用的时间，一个是影响效率，另一个是消耗时间，做的大多是重复工，进而影响成长，我想要的是生成大部分代码，只保留业务逻辑部分，我只需要考虑这部分就可以。

解决掉以上的问题之后，我的组件只需要做好，然后配置丢到容器里面就可以，操作过一两次熟悉之后，就不再形成瓶颈，而我需要的实现业务逻辑就可以，而且大家都统一，沟通成本也没那么麻烦。

这样可以把精力在这块上面，包括文档和处理思路，出来的编码还有文档，质量会更高很多，而不是需要我再整理N多的东西，统一发出，再搞很长的解释，还有后期不断的咨询到这里。

数据以更好的辅助应用的建设

一样不喜欢一上来就讨论n多的技术和业务无关的，有个文档，简洁的告诉1、2、3点就可以，其它的不想关注。

应用跑的过程，会产生日志，包括请求、用户访问，有些表的数据过大，而又非业务数据，需要定时删除，报表统计过程中，应用过程中表结构已经定了，不好再对表进行修改，除了报表还有运营的数据，这些指标需要定义，还有过程数据需要采集回来再运算等。

这些都是数据层的处理，在没有数据仓库之前，无法挖掘，或者这个成本较大，另外数据存储问题也比较大，再然后就是数据计算出来之后，又需要提供给业务，两者互相并辅助。

还有就是想做一些机器学习，挖掘业务使用场景，创新业务和方案的查询，同第三方系统，多个系统之前的交互，也无法做到，也就是常见的数据孤岛问题。

还有等保安全要求等等。

这些还需要思路放哪里，怎么放数据，还有这些流程怎么样，规范是怎么样的，需要的是，生成对应的初版脚本，我只需要修改我的逻辑部分就可以，然后数据自动采集到数仓就可以，按规范来处理。

在挖掘上，我只需要拖动每个数据处理流程，形成工作流输出就可以。

支撑我的解决方案文档落地

写方案，非业务的，不想再找n多的文档，而且找不到稳定的方案在哪里，需要到底问人等材料，需要快速铺商务

在解决方案上，需要一个强有力的平台进行支撑，针对不同的业务，需要集成的不同能力，进行各个服务或者应用进行整合和支撑，拼凑起来就可以，而不需要到处询问，或者说到处查阅这个组件在哪里，怎么支撑。

能有演示，可以让整个串并跑起来，而且我也能看到，确定可用，这为后期商务上做好支撑，同时也是给客户商务过程提供信心，以提高在各个过程中的竞争力。如果业务应用没有怎么办，跟ISV整合即可，即使一下没有，那也只是单独处理的模块，并不需要我再从零考虑这个方案落地过程中的太多问题。

而且这个过程，报价居高不下（除了商务策略以外），内部成本也无法评估，让利部分也没底，整个下来，跟竞争对手对比上容易底气很不足，更别说打动客户了，可能打动自己人都比较难。

比如一个简单的场景例子，应用上的沉淀和数据的沉淀，这两块在规范上形成自动化，这个成本上基本上就低很多，另外在客户演示或者项目前期，基本上就可以马上搭建部署进行一期，各个申请资源还有管理就走下来，推动项目的进程，难道还需要考虑等开发出来才能实施，这个交付周期就拉长了。

后期维护

需要的是不断升级和维护一个中台，集中精力在这个上面

我不需要迭代今天一个明天一个技术框架，也不需要每个都要重新建设一次，走一次流程，需要不断的迭代，一个是熟练，另一个是大的流程不变，当中可能升级某个点，但是升级之后，需要兼容前期的接口还有框架，这个在高级工程师和熟练的情况下，问题其实并不大。

这样在过程两三年的迭代中不断的优化，稳定性更强，健壮性也更强，类似于一辆车，单独换发动机并不影响，可拆可合，根据不同的场景进行不同的沉淀，以达到更强的配置。

其它

到这步，其它人怎么使用其实在我这里关联并不大，而我需要的是解决我的问题，而中台架构并不代表说它是一个死的架构，这个可以根据过程不断的调整和优化的，这个概念和架构的提出，会更加明确搭建和建设的思路和方向，但是怎么实现，需要架构师根据团队来进行优化处理。

在这个过程中的感觉好比别人送给你一个屠龙刀，会使用的人可以扫四方，但是不会使用的，可能会惹火上身，伤到自己，甚至会发现，还不会以前菜刀方便，关键是怎么使用。