近两年来，个人有幸参与了最火热的业务中台的建设工作，虽然还没有成功，但也有了一点点成效。本着开放共享的精神，将一些心得体会总结出来，给业界同仁们一些参考，尽可能少走一些弯路。也希望正在中台之路上一起探索的、我的同事们更加深刻理解我们共同在做的伟大的事业，共勉共进，相信不久的将来必然能共同见证这一伟大的软件生产方式的变革所带来的价值。
“烟囱”及闭环思维的优势
业务发展初期用户的需求都是不稳定的，需要以敏捷的方式进行快速迭代交付，为业务的生存和发展争取时间。这时候，整个业务是闭环的，尽可能减少减少外部依赖，因为外部依赖通常会带来很大的不确定性。为什么这样讲呢？从以下几个方面做个简单分析：
1）从研发角度看，如果依赖了外部服务，当出现个性化需求依赖服务无法满足的时候，需要跨部门协调申请改造和排期，有时候可能会由于排期无法满足而导致自身业务交付的变慢，远不如自己把控代码直接修改来的快；另外如果使用了大量的外部服务，开发者无法增长实战经验，对研发人员的自身成长是不利的。
2）从项目管理角度看，依赖的外部因素越多，那么系统交付的周期就会越长，在开发、测试、预发上线各个阶段都需要集成联调，首先在涉及到跨部门沟通中，效率上会大打折扣，其次进度上如果有一个外部依赖的关键环节延期了，就会导致自身项目的延期，因此对于交付是不利的。
3）从运维角度看，在线上系统出了问题的时候，依赖的外部因素越多，排查问题的难度越大，所以在SLA要求越高的系统中，越不敢使用外部依赖。每一个外部依赖都可能会成为诱发线上故障的隐患，一旦出了故障还要协调外部门帮助排查、处理，这种情况下故障修复的时间会比较长，而自己掌控的系统则可以做到尽快的恢复。所以开发者通常不愿意用外部依赖服务来交付，除非那些依赖的服务是被证明非常稳定的、用户案例足够多的。
因此，对于项目的交付者来说，所有的核心业务系统及周边支撑系统，都需要尽可能地在自己的掌控中，虽然有很多重复的建设，但是可控性更高，对于高效的持续交付更有保障。因此，闭环思维也有着很大的优势，尤其在业务开创的初期。
随着业务的发展，业务线上已经有了一些客户，业务系统的功能也有了一定的基础。突然有一天，领导说又搞定了一个客户，大家看看怎么办？首先想到的肯定是复用现有系统，但经过研究发下，现有的代码能满足绝大部分，但少量的个性化需求无法满足。这个时候90%的开发者都会考虑复制一套代码，基于新的拷贝在进行修改定制，以快速地满足客户的个性化需求，这样能最大限度地保证交付的速度和可控性，即使有了bug也可以快速修改。此时有一些开发者会纠结，以后两三套代码怎么维护呢，但纠结还是被交付时间打败了，开发者没有任何动力在这个时候去做重构，因为即使加班也很难按时完成当前的交付。
如此以来，团队进入了一个怪圈，每个客户都是紧急的，随着客户越来越多的时候，多年下来同一个业务领域内就存在了多套业务代码，像用户权限这种公共系统也都一大堆，但又各有不同，每一份拷贝和分支都有其存在的理由。下面用一组几何图形来演绎下业务需求和软件系统是如何不断累积的、演进的，我们发现越到后面分支越多越复杂，最终形成了“烟囱”林立的局面。
虽然“烟囱”林立，但一切都还是OK的：
1）客户：每个客户都有一个一对一支撑的项目组，客户也很满意。
2）老板：客户越来越多，人力成本越来越高，但是项目的利润还允许增补人手。
3）各团队负责人：每一个项目的团队越做越大，团队负责人也很高兴，没人希望自己的团队越做越小吧。
4）各团队成员：每一个项目团队的成员各自在自己的小闭环中忙碌着，虽然加班较多但还是能按时交付，也能学到东西，运维也还好，有时线上会出故障，但能及时修复。
直到2018年秋天，随着资本市场的变冷，一场风暴在各大公司开始酝酿。业务需求在压缩，同时资金不足以支撑新业务的烟囱式扩张。试想对于一个有一定规模的公司来说，如果成百上千甚至上万的研发都通过烟囱式的方式去交付，其实是比较恐怖的，这种业务扩张的成本太高了，终有一天会难以为继。因此，必须找到一种能够实现软件规模化创新的新的生产方式。中台正是目前解决这个问题的最佳途径，9月份开始各大互联网公司刮起了中台风。
中台努力的方向和目标
通过以上的分析，可以得出烟囱模式和闭环思维的是有很多的优越性的，如果中台想成功就必须能够保持这些优势，否则很难证明中台模式是先进和优越的。我们做中台不是为了跟风，也不是为了做中台而做中台，需要凸显其价值才有可能成功，而仅仅是可能。中台不是一朝一夕建成的，每个公司的情况不同，都需要长时间的探索和协同，找到适合自己的方法。以下是我们在实践中总结的一些努力的方向和目标，基于此制定的中台建设方案成功的几率会增大，此处仅供参考。
1）保持甚至超越烟囱模式下的交付效率
2）能大幅度降低新项目和新需求的交付成本
3）支持个性化需求的快速定制
4）跨部门协同的效率保障
5）降低系统改造上线的风险
6）全链路快速定位线上故障
7）关注各团队成员的自我成长
中台路上的十道坎儿
第1道坎儿-寻找业务痛点和突破口
一切工作应该以价值思维、痛点思维为导向，在解决痛点中产生人们认可的价值，没有价值产出的努力是无效的。没找到实际业务痛点就做中台，十有八九会失败。中台的建设不是一朝一夕就能搞定的，如果领导层和同事们看不到中台的带来的价值，久而久之就会产生动摇，失去坚持下去的耐心。
判断某个业务是否适合做中台化改造的一些建议：有较大的重复建设，至少有三套及以上重复的代码，且相似度超过60-70%以上；需求旺盛的业务，特点是需求频率较高，成本投入较大，改造后能大幅度降低开发、测试、维护成本和提升交付效率的优先考虑。这两个条件缺一不可。以此突破口作为中台建设的标杆案例，成功概率会较大。如果找不到合适的突破口，很大程度上说明可能不适合做中台。
第2道坎儿-把中台确立为公司的战略
中台建设是一把手工程，需要跨部门的深度协同，产研运协作，研发内部跨部门协作，没有高层的推动中台建设工作推进难度较大。找到突破口后，有痛点分析，有数据分析，有明确的ROI计算，形成汇报建议方案，尽可能获得老板的认可。公司把中台确立为公司的战略，然后进行整体宣贯，自上而下，所有干系人达成共识，且有明确的KPI逐层拆解，确保中台建设者变革的决心和强大的执行力。防止在实施过程中陷入到做表面功夫，换汤不换药，则实施效果会打折扣，不利于后续的推广。
第3道坎儿-能描绘出中台愿景
战略确定以后，人们大部分还是懵圈的，大家只知道领导说了要造中台，啥是中台，没人能给出明确的答案，每个人的理解会都不一样，在初期阶段所有的人的认知都只停留在概念上和外部中台的认知，所以要讲清楚你的公司造的中台是什么，是业务中台、数据中台还是技术中台，要能描述出中台造完后是什么样子，这样大家会有一个具象化的认识，也能统一思想、方向和目标。在这里抛一下我个人的理解供参考：中台是共享的业务、数据、技术平台，前台是是具体的业务线，使用中台的能力进行面向客户的交付，前中台有明确的分工和协作流程，有一定的沉淀机制不断壮大中台的能力。大体上朝着这个方向，差不多应该能描绘出自己特色的中台的愿景。
第4道坎儿-建立中台思维
中台是一场变法，变的是创新之法，由闭环思维走向中台思维。从什么都想自己造到主动去使用别人的轮子，把自己的后背留给你的中台伙伴，需要有足够的勇气相信自己的中台伙伴会为你的后背挡刀，而你则可以心无旁骛的向前冲，这也是一种协同的思维。尤其是在中台建设初期，所有的共享服务都需要打磨，稳定性和bug都是难以避免的，因此需要前中台所有的建设者们具有突破难关的决心，方能有所成。这种思维转变最为困难，需要一个较长的过程，如果有绝对影响力的大牛做背书效果会比较好，另外也可以通过点燃一个火种，并且能小范围燃烧起来，要让人们能够看到效果，也可以加速转变。
第5道坎儿-有明确的实施路径
从战略的确立到愿景实现之间需要确立一条清晰的路径，就好比中国革命当年是要走城市武装起义的路线、还是走农村包围城市的路线，不同的路线会有截然不同的结果，这是一个不断摸索的过程，虽然会有曲折，但必需找到适合自己的实施路径才可以提高成功率。国情有不同，各个公司情况也有不同，所以走的路线自然也不一样，别人的可以参考，最好不照搬照抄。在这条路径上，可以考虑以下因素：
1）应对业务需求的压力，一边接需求一边重构，风险低，投入低，周期会拉长，新老系统并行很痛苦？还是直接推倒重来，最后直接切量，高投入，高风险但见效最快？
2）组织的变革，是明确的组织变化还是虚拟组织，是否必要建立横向统筹的组织？
3）领导层是否有足够的耐心，是否有足够的资源投入？
4）是否有强大的攻坚团队，虽然很难，但能够一直坚定地探索下去？
以上的一些建议因素并不全面，但都或多或少会影响这条路径，最重要的是能不断地保持某一阶段的正确性，发现问题及时调整，才能够一直走下去。
第6道坎儿-确定方法论
方法论是理论的武器，要做成事情要有一整套的打法，用于指导后续中台建设的实战。在中台建设中用到的方法论有：前中台分离、业务流程融合、需求结构化治理、业务领域建模、需求配置化、扩展点等方法。前中台分离是最重要的方法论，中台的第一目标是实现前中台分离，实现业务个性与共性的分离，个性开发给前台，共性沉淀到中台。前中台分离还会涉及到职责再分工，从原团队中切出前台团队，独立承担个性化业务需求，有利于中台整体价值的体现，达到缩短交付周期的目的。前中台分离还会影响测试的范围及相关标准的调整，对稳定的中台组件加大自动化回归测试的力度，进一步削减人工成本，对个性化前台业务明确测试范围进行专项测试。方法论是需要不断迭代演进的。
第7道坎儿-有流程
中台实现了职责分工的调整，需要有一套新的流程为业务需求的落地提供保障，这里的流程主要指前中台协作流程。业务需求先抵达前台产品，判定是否可以利用现有的中台能力完成交付，如果不能则继续判定是共性需求和个性需求，个性需求则前台研发实现，共性需求则需要向中台产研提出需求。中台产研受理需求进行业务组件重构支持共性业务，丰富中台能力。中台能力完成后交付给前台产研，最终通过前台产研完成需求交付。整体的流程需要前中台产研深度协同，流程不畅会降低中台的实施效果。在初期可以通过树立标杆进行检验，再逐步扩散。
第8道坎儿-有机制
机制是中台持续发展的动力保障，良好的运行运营机制可以驱动中台向好的方向持续演进。比较重要的有KPI考核机制、业务需求仲裁机制、业务沉淀机制（前台的个性化功能定期沉淀到中台）、架构治理机制（公共能力管理，统一技术栈和UIUE等细节）
第9道坎儿-培养核心人才
中台的落地需要有一批核心人才支撑，中台建设本身是一个不断探索、不断迭代的过程，需要有持久的激情、强大的内心，遇到困难想办法突破，不轻言失败。需要培养一批既懂业务又懂技术的领域架构师掌舵，中台流程、机制的执行，需求的仲裁需要靠领域架构师来完成，掌控落地的关键细节，降低实施中的风险。
第10道坎儿-度量和考核方法
做到什么程度算完成了中台化改造，改造的组件质量如何，如何评判？领导们如何感知到中台建设的进度，所处的阶段？因此需要一套度量和考核方法，可以通过建立中台的大盘指标来实现。指标可以分为过程、结果两种。体现进度的比如可以设置中台化改造率，体现结果的比如需求交付周期是否缩短等。通过大盘指标来整体反应中台的建设情况及成果。
中台必成的信念
罗马不是一朝一夕建成的，相信办法总比困难多，只要拥有一往无前的信念，中台也一定可以建成。愿诸位同仁一起加油，共进共勉。