相信很多同学读过储总那篇《建设中台能力，助力开放生态》的分享，高屋建瓴，敏锐的洞察力，值得细读。那么，基于此篇内容，来个班门弄斧，从一个架构师的视角，结合行内实际情况，来聊聊我理解的“业务中台”，抛砖引玉。
中台，已经“火"了好几年，唱“多”唱“空”也是此起彼伏，估计大家都有点审美疲劳了，我就不啰嗦中台本身了，从问题出发，看本质。
1. 阿里推进中台建设的历史原因是什么？
都知道，中台是从阿里唱起来的，那么阿里推进中台建设，历史原因是什么？
在移动互联网前期，成功的互联网产品前期一般是野蛮生长，用户爆炸式增长，用户、产品需求多变，商业模式也可能不断调整，有比较强的不确定性。
这种情况下，业务系统（无论业务上还是技术上）都以解决实际问题为导向，怎么快怎么来，在不断的填坑和挖坑中，不断向前演进和发展，基本不可能像传统系统软件那样，根据确定的需求和用户，用1、2年的时间来，设计，建模，开发，测试，最终上线。
所以，前期根本没机会考虑多渠道能力复用，在架构上、设计上，肯定没有，因为没有需求，也顾不上。就算考虑了，也是白费，因为产品、商业模式还没成熟稳定下来。
当互联网产品的业务模式、商业模式成熟，线上用户规模触顶，单一渠道业务规模增长成瓶颈之时，必然走向线上线下多渠道、横向B端合作的渠道多样化发展。当渠道越来越多，越来越多样化，经营越来越精细化，渠道间协同，复用降低成本的问题和需求就出来了。
这个时候，已经站稳了脚跟，是时候好好总结，好好建建模，抖一抖历史包袱，夯实一下护城河。
阿里当时的情况是：移动App经过野蛮生长，已经超过PC，在移动互联网站稳了脚跟，成为“组织内最大的一根烟囱“，如何进一步整合PC等渠道，夯实移动互联网的“船票”，“中台”横向整合正是这味“良药”，这应该是阿里推进中台建设的历史原因。
但金融行业的历史情况，是恰恰相反的。银行业IT沉淀多年，业务和商业模式相对成熟稳定，业务系统都是根据确定的业务需求，经过严格的建模和设计，瀑布开发模式做出来的，而且大部分是厂商多年沉淀做出来的。
银行业的渠道本身就是多样化的，自身渠道从线下发展到线上，比如：柜面、ATM、电话银行、PC网银、线上App等；金融作为商业基础，外部B端合作自然也不少。
从技术上，我们也可以看到银行的系统架构分层早就分成渠道层和核心层二层，很多核心业务系统的设计上，本身就是支持多渠道的，比如：D+、基金理财核心业务系统等。
所以，银行的架构早就分出了前台和中台，也有众多的中台系统。
最近看到文章，某证券的CTO讲他们比阿里更早推进中台建设，也是这个原因。记得14年，我整理平安信托架构时，整体架构图上也是明确提出“前台、中台、后台”三层的。
所以，金融行业基本就是这样的架构分层的，跟互联网企业区别在于是否自主研发、是否依赖厂商。
最近3年，业务上，我们自主研发，去掉厂商依赖，IT团队由“搞物业”的，成功转型成“建房子”的；技术上，去IOE，微服务化，向开源的技术栈靠拢；业务系统基本上完成了自主掌控和现代化改造，相对于互联网企业，也算殊途同归。
2. 阿里为什么把中台当战略来推进？
中台只是一种架构模式，业务发展引发的一个技术问题，上升到“战略”高度，背后逻辑又是什么？
战略的逻辑，是因为”未来“需要。是因为看到了，移动互联网的下半场是产业互联网，机会在“B"端，互联网将变革各行各业，必然带来更多"B"端合作和场景，渠道也将更加多样化，更需要有强有力的中台支撑新渠道的快速成长。
所以阿里等互联网企业，无论是业务布局上，还是组织架构上，都进行了调整，布局产业互联网。中台战略，是布局产业互联网的一环，就像13年提出“All in 无线”一样，吹响号角，组织动员。
另一方面，互联网产品成熟稳定之后，也很难进行颠覆式的创新，推进“中台战略”也是夯实护城河，利用已有的优势和流量，支持护城河外的创新，在护城河外建立共赢生态。
回到银行业，金融是所有商业活动的最后一环，和互联网企业分处二端，虽然护城河不一样，所处位置不一样，但都需要产业互联网发展中，支持各行各业数字化转型，建立合作生态，夯实护城河。
我行推进”开放银行“战略已近2年，中台建设也算是此战略的支撑和延伸，助力开放银行，建立外部合作生态。
3. 我行中台建设面临的最大挑战是什么？
如何做“大”，应该是中台建设的最大挑战。“大中台，小前台”，关键字是”大“。
那么，什么才是“大”中台？能充分使用“大数据中台”的能力，做到 KYC（客群），KYCC（渠道，渠道的客群、渠道的场景）、KYP（金融产品，经营闭环），强有力地”赋能“前台，才是“大”中台。
我行的中台系统并不少，如：D+、A+、外汇业务系统、基金理财产品系统等等，但它们目前还不能说是“强有力”的“大中台“系统，能强有力地赋能前台渠道，支撑新前台渠道成长，解决前台重复建设问题。
个人观点，目前只能算是”大前台，小中台“。大中台是因，小前台是果，中台如果不能做大，价值和意义折半。
数据时代，如果没有充分利大数据中台的能力，支持精细化客户经营，渠道多样化发展，这样的中台系统，是不能满足我行下一阶段发展要求的。
行内的中台系统，基本上只做到KYB（金融业务），基本可以做到模块化，参数化，对外提供”原子能力接口“，形成稳定可靠的中台业务系统。
使用大数据中台能力，目前基本是前台系统在做。如果没有充分组合“大数据中台”的能力，只是提供“原子业务能力接口”，这不能算”大中台“系统。
你的设计模型里，应该有客群、场景大类、渠道大类等属性才对；你的代码里，针对客群、场景大类、渠道大类有不同的逻辑处理才对。
你的系统里，有客户旅程、金融产品、场景的闭环管理、关系处理的逻辑才对；你的系统里，有以客户为中心，处理渠道间协同、断点续接的逻辑才对。
你的系统设计上，能同时支持全渠道接入（行内自有线上线下渠道、外部合作渠道）才对。
你的系统里，要有处理金融产品复杂度的逻辑，做到轻代码（NoCode）可配置化，简化前台接入，灵活应对前台需求变化才对。
4. 业务中台如何做”大“？
中台不是规划出来的，是将成熟渠道的成熟能力，总结建模下沉到中台，赋能前台渠道。当下沉的能力越来越多、越来越强，中台就“大”起来了。
作为前台渠道，中台已有的能力尽量复用，如果中台能力不能满足需求，则可自行孵化建设，成熟后再总结下沉到中台，或者前、中台合作，直接在中台孵化新能力。
这样前台和中台，才能形成良性循环。中台也不会成前台生长的阻碍，前台能力不断下沉，中台能力不断变强，对前台支撑能力也就越强。只有这样，中台慢慢变大，前台才能慢慢变小，才能把“大中台，小前台”做实。
5. “大”中台建设对行内现有架构的影响是？
行内架构，目前是分二层，渠道层（前台）和核心业务层（中台），我们的组织架构上，也基本是这么分的，分渠道研发团队、核心研发团队（我觉得可以改改名，可以改为中台研发团队、前台研发团队）。
面向“大中台”建设，架构上主张增加一层：大中台层，规划大中台类别的系统，组合大数据中台、技术中台、核心业务层的能力，业务上做到KYC、KYP、KYCC，技术上做到建好模，轻代码(NoCode)可配置化，灵活应对前台需求变化。
现有核心业务层（业务中台层）不变，提供并持续加强原子业务能力的建设（KYB）。
6. “大“中台建设对研发团队的要求是什么
视业务需要构建大中台业务系统，调研前台能力、痛点、问题，去学习使用大数据中台、技术中台的能力，
然后进行能力规划和模型设计，将前台成熟能力下沉下来，然后让前台自愿将这些能力用起来。
大中台系统建设，对研发团队的要求还是很高的：
1. 尽量结合新的前台渠道（如开放银行）的需求一起做，评估成熟渠道（如口袋App）已有的成熟能力，根据精细化经营的诉求重新建模，下沉下来支持全渠道。
2. 前台尽量复用中台能力，但不强制前台使用中台能力，中台能力不满足需求时（能力上，时间上），可由前台自行建设，满足自己的需求，待成熟后再将能力下沉。
也可以由前台、中台团队合作，直接在中台孵化新能力（由中台团队主导，确保中台定位和边界），来满足前台需求。
这样也能避免前台争抢中台资源，影响前台“打粮食”，也避免中台被前台牵着鼻子走。
3. 在复用的前提下，中台要为前台提供业务解决方案，夯实企业护城河；中台要把复杂留给自己，简单留给前台，让前台自愿用中台的能力。（这点要求挺高的）
4. 少做规划，少搞运动，保持克制，尽量以解决实际问题来建设大中台。大中台得大，但不是立马要做得很大。
5. 建模很重要，0到1起步的架子很重要，设计上要留余地，需要资深架构师深入理解业务后构建起来。架子搭起来后，能力根据实际需要，慢慢下沉建设。
6. 要仔细评估前台能力的可复用性，渠道所特有的，暂时不具备复用价值的，就不要下沉，有用再做。不成熟的能力，也不要急着下沉。
中台的边界很重要，要有所不为，需要把握好。重视设计，把控好设计。
7. 推进落实“DDD领域驱动开发"，“TDD测试驱动开发"，灰度发布及变更，轻代码(NoCode)业务流程编排等技术手段，确保中台模型稳定和质量可靠，做到安全无损变更；插件化、配置化，应对前台需求变化，尽量能做到不变更，以不变应万变。
ps: 这些技术后续再发文单独解读，内容也不少。中台要做好，没点技术追求是不行的。
8. 常规需求交付与项目攻坚相结合，骨干力量”攻城“，解决关键问题。单纯的需求交付，做不出中台的。把大需求集中起来，形成项目，实施攻坚。
9. 现有的核心业务系统（如：D+），应该保持简单、稳定，做强做活原子能力（KYB），不突破现有定位和边界。
10. 要彻底的微服务化，区分核心模块和外围模块，差异化版本周期，做好解藕、限流、熔断、降级。
11. 做好接口文档，接入指南，Demo，联测环境，前台同学能“自助化”对接、开发、联测。
总之，中台的挑战是“做大”，“做大”的挑战，一则在业务上“能否真正赋能前台”，中台对前台的价值闭环在：去重-复用-赋能。
二则在技术上”模型建得好不好“，成熟稳定的数据模型，业务模型，业务流程模型，做到轻代码（NoCode）可配置化，让前台简单接入，能轻松应对前台需求变化。
7. ”大中台建设“对业务团队的要求是什么
大中台系统也有业务属性，业务范围，如何衡量它的价值，如何衡量它做得好不好，不大好量化。中台团队如何做得有成就感，愿景是什么，也是个问题。
前台相对好办，定KPI，看业绩达成。当然，目前的中台团队也有这个问题。
前台能不能做小，前台有没有大量的重复建设，中台是否高效赋能前台，是衡量中台做得好不好的标准。需要定期检视，定出一些量化指标出来。
另外，金融产品、场景的经营闭环，客户断点续接转化，渠道间的协同，应该也可以定出一些量化指标出来。
大中台系统的业务Owner，需要转型成“中台产品经理”，需要主动去了解渠道共性、场景共性，需要主动去理解客群需求，需要主动去了解前台的需求、痛点、问题，需要主动去学习使用大数据中台的能力，促进大数据中台的能力建设，这样才能构建更精细的金融产品经营闭环，场景经营闭环。
中台要理解前台，中台产品经理最好是由前台产品经理专职轮岗；要把中台业务系统当“产品”来做，建立产品委员会，根据业务发展、战略需要，确定中台系统发展路线图，并实施落实。
大中台建设，即要从业务价值视角去驱动，也需要从技术视角去驱动。对“人”的要求更高，更需求IT与业务的紧密配合，共同推进。
总结一下
个人观点，我行的中台建设进入“大中台建设阶段”，业务上看是需要的：开放银行外部渠道多样化发展、自有渠道精细化的客户经营，时机应该也是对的：大数据中台、技术中台建设基本完成，行内系统现代化改造基本完成，产业互联网的迅猛往前发展。
这个事情，做是简单，做好是挺难的，但这个步子，该迈出来。
我们需要，结合开放银行侧的业务发展和突破、行内自有渠道的精细化经营需要，从解决实际问题出发，长短结合，有步骤地展开“大中台建设”，也不需要搞突击、搞运动，它需要长期持续做下去的。
没有银弹，前台重复建设必然存在，只是多和少的问题，也要允许”大前台“的存在。中台应该是尽量减少前台的重复建设，尽可能高效赋能前台，让前台快速响应市场变化，这应该是中台建设初衷。
产业互联网在物联网、5G、AI等新技术的加持下，加上“新冠疫情”这个催化剂，各行各业数字化转型正当时，金融处于场景的末端，有可能后知后觉。
“得场景者得天下”，回顾移动互联网前10年，再想象未来10年，深感想象力是匮乏的，也能感受到银行业的危机感，监管只是放慢了互联网企业的步伐，趋势不会改变，跨界打劫者也永远存在。
当然，我们也在改变以适应这个趋势，比如，最近看到网点2.0往社区银行方向发展，职员服装由制服改成了休闲服，也是为了贴近生活，掘取更多的场景。比如：绿洲项目（头号玩家里的“绿洲”，名字就起得很有野心），在探索适应物联网的人机交互模式和场景。
建设好大中台，有力支撑开放银行战略，在护城河外建立生态，掘取更多的场景，这应该是战略初衷。
最近领导安排做中台调研，深感个人认知是有限的，个人观点也必然有局限性。大中台建设是需要每个人去做的，把个人观点表达出来，希望能抛砖引玉，引发大家思考。
希望大家能结合自己的工作情况，抛出更多的不同观点，集思广益。
