技术人员对数字中台能力使用的使用

背景

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

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

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

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

思路阐述

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

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

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

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

怎么使用

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

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

日常使用过程的方式，以小见大，需要一些团队管理的想象而扩大到团队。

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

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

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

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

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

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

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

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

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

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

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

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

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

还有等保安全要求等等。

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

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

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

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

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

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

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

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

后期维护

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

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

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

其它

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

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