基于资产配置模式下的技术中台实践

1、基于资产配置模式下的技术中台实践讲在最前中台解决的是避免烟囱式的产品，同时大幅度降低新产品的构建 成本和运营成本。微服务解决的是单个模块的复杂度问题，分离关注点，降低重构 难度，容许各个单元技术上异构。讲在最前“中台不是一种技术实现，而是一种技术战略。”“除了技术、业务，还有数据和组织。”目录在什么情况下，技术中台才会有价值？1技术中台实践过程中的问题与挑战2未来的路该怎么走？3业务系统的演进技术中台的前提业务系统发展历程012012 - 20131.0单体+单产品032017 - 20183.0重新定义022014 - 20162.0单体+多产品1.0时代：单体+单产品2.0时代：单体+多产

2、品前台负责部分业务拼装缺少分层，系统相互调用基础组件五花八门多套运营后台3.0时代(业务)：多业务线+组合/创新3.0时代(系统)：多业务线+组合/创新业务系统的演进技术中台的前提很多美好的结局，都起源于领导的一句话领导晚上做了个梦，醒来给我打了个电话“要不咱们也搞个中台玩一玩？”中台是“建立”起来的，还是“演化”出来的？搞中台？ 是不是闲的 蛋疼？前提1：技术组织结构垂直化1前提2：业务线又多又复杂21.0&2.0时代：按职能模式划分的组织1.0&2.0时代：按职能模式划分的组织“瞧瞧这结构，有什么问题吗？”成 本效 率或质 量或3.0时代：每个团队都围绕 “交付速度” 开展工作痛点：因“屁

3、股决定脑袋”而引发 多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积 累，无法得到统一的保障。 开发与测试、运维之间目标不一致（比如测试A君，开发要求你只做功能测试，快上 线，但测试老大却要求你做非功能测试，保障质量，避免背锅到底听谁的？）， 陷入永无休止的扯皮与争吵。3.0时代：每个团队都围绕 “交付速度” 开展工作 目标：技术服务下沉，快速试错，小步快跑3.0时代：每个团队都围绕 “交付速度” 开展工作方案：因“穿同一条裤子”而解决 成立平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。 把质量管理部中的测试团队，与系统运维部中的应用运

4、维团队，按照系统功能拆分至 各开发团队，由原开发经理负责，形成各自独立的Feature Team。中台是“建立”起来的，还是“演化”出来的？搞中台？ 是不是闲的 蛋疼？前提1：技术组织结构垂直化1前提2：业务线又多又复杂2多业务线+组合/创新，对系统建设带来的挑战多业务线+组合/创新，对系统建设带来的挑战申购 确认赎回 确认取现购回赎 回 确认赎存入储蓄 罐申 确购 认确认购过确 认份额结转储蓄 易对各类创新业务的增加公募 + 储蓄罐000667时取 现过账储蓄罐份额账储蓄罐份额结转储蓄罐交易对账 罐交账TA转换482002时基代金创新 买入储蓄罐买创新对账支付 取现？ 回？存购入？赎回？申申

5、购购 赎回申？ 存入？申购 ？赎回 确认代储蓄公公募募？+ 储罐蓄买罐确？认 赎回 ？ 申？ 份 额储蓄 罐？支付赎？回申到储蓄罐 赎 ？ 业务创新比较多，需要前后台系统定制开发，逻辑兼容难度增加。 业务逻辑分散，缺少统一适配层，每次测试工作都需要 ALL IN。多业务线+组合/创新，对系统建设带来的挑战01金融全产品客户资产配置要求系 统能够同时支持多种 金融产品的交易流程系统高复杂系统需要支持多种金 融产品， 并且还需要 降低运营成本， 并考 虑监管的因素0203运维成本高基础组件裸用， 技术 选型使用五花八门， 运维成本居高不下从“抓壮丁”，逐渐向事业线制转化 技术中台的作用是什么？有点

6、像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业 务能力分离，并以产品化方式向前台提供 技术赋能，形成强力支撑。测试、运维打散到产品线，是否能高效跑起来，要看中台资源整合的能力目录技术中台实践过程中的问题与挑战2在什么情况下，技术中台才会有价值？1未来的路该怎么走？3关键思考在你的印象里，企业文化 对 技术中台 的落地会产生哪些影响？企业文化没有对错，合适即可与阿里云在阿里的落地腾讯云在腾讯的落地技术中台演进所面临的3大挑战屁股决定脑袋该死的技术债众口难调场景1：前台与中台之间的“矛盾”多个团队，多套代码，多套 标准，服务多家客户，但这 样一来成本又难以承受，时 间一长，肯定资不

7、抵债。一个团队，一套代码，一套 标准，服务多家客户，但客 户不买账，客户说我的需求 都是个性化的，你别来某某 标准来引导我，叫你咋做， 你就咋做，不愿意？那您走， 我找别人家做。随着用户数的增多，成本与效率/质量的矛盾日益凸显。一个团队，一套代码，多套 标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品 化平台，但对技术投入要求 较高，尤其是核心人才的依 赖较大，中小型企业一般都 很难留住这些人，只要他们 一走，公司基本完蛋。一对一服务 - 项目制一对多服务 - 标准化一对多服务 - 产品化场景2：该死的技术债 举个栗子：A团队和B团队，同时需要接入分布式缓存系统。场景3：谁说了都算，谁说了都不算老板的经验技术债务抄袭别人目录未来的路该怎么走？3在什么情况下，技术中台才会有价值？1技术中台实践过程中的问题与挑战2技术人和系统的 成长依赖于规模效应。但可悲的是，很多系统和人都活了十几年，虽然没死掉，但也没 长大，有经验的人没留住，技术投入也越来 越小。思考：下一步，技术中/后台的路该怎么走？或继续自研逐步上云结论：我们选择腾讯云，并逐步上云原因1：投入下降业务模 式