标签：良好的 客户 实现 联动 back 战略 为我 环境 ice
参考：
https://mp.weixin.qq.com/s/dpkteHsQJ4Rwl6YNl2PVeg?
https://mp.weixin.qq.com/s/TirTQfWo0gX9PUw_okdGjQ?
“平台化”是架构师经常用的一个词汇。什么样的设计实施可以称之为良好的实现的平台化，其实见仁见智。杨密总言道，我一般把平台发展划分为组件化、服务化、系统化。组件化是基础建设阶段，第二阶段就是服务化，由基础衍生到服务阶段，不区分业务或组件服务，为了后续的提速开发、规范、套用等。第三阶段则是微服务的成熟产出系统集成，产品输出，个人习惯称之”系统化”。 我理解此谓系统化就是平台化的一种表达。
大略大家熟知的平台有SAAS平台、PAAS平台。比如阿里云的EDAS平台，定义如下：
EDAS 是一个围绕应用和微服务的PaaS平台，提供多样的应用发布能力和轻量级微服务解决方案，帮助用户解决在应用和服务管理过程中监控、诊断和高可用运维问题；提供开源软件Dubbo的商业版。
关键字：应用运维、微服务、Dubbo、SpringBoot、鹰眼监控、服务治理
一个良好的平台，需要有确定的职责、内涵和外延。简单点说，就是做什么，不做什么；如何与其它平台协同。
Eclipse无疑是一个良好的平台，为无数开发者津津乐道，诸多企业研发产品都可以基于Eclipse做二次研发。基于 Eclipse 的应用程序的一个突出例子是 IBM Rational Software Architect，它构成了 IBM Java 开发工具系列的基础。
【平台化三部曲之一微核心可扩展架构 - 从Eclipse平台看交易平台化】一文的作者谈到，平台的开发，一般包括两方面的内容，一个是可复用性，一个是可配置型。Eclipse作为成功的开发工具集成平台，这两方面提供了很好的典范。从某种程度说，平台化就是领域平台化，也和SaaS化有很大的目标一致性，能够快速支持多业务的定制开发，同是保证业务之间互相隔离。比如交易平台化，你需要在一套交易系统中支持多种交易模式，多种业务实现。阿里的中台化战略就是建立在业务系统平台化基础上的协同。
总结，平台化架构的特点，简单易用、可扩展、业务隔离。如下图所示：
这里展开说一下，上图为示意，通过平台目标可以推导出架构特性，比如如何做到易集成呢？简单易用是不是可以进一步阐述为易安装、易配置、易运行？Eclipse则提供了良好的plugin机制来实现扩展性。一切都是插件。它自身就是一个基础平台和框架。
以电商平台或者第三方支付的架构为例，进一步解释一下。比如支付平台从能力上提供了支付、退款甚至冻结、解冻等；那么支付平台对上层业务平台提供了服务化，组件化，甚至可视化编排的能力、研发各种工具、甚至支持扩展的plugin，示例、环境等。但研发工具、运行时管理、研发生命周期管理等可能由中间件团队、质量工具团队提供支撑。
为什么会出现平台化架构，还得从烟囱型架构说起。回首我司营销工具的发展，百花争艳，变化万端。早期，很自然的是来一个业务，做一个（一套）系统去支持它。热火朝天干上一两个月，业务支持上了，但后续的维护是很大的问题。
业内人士把见招拆招、垂直化发展、未做足够抽象通用的架构称之为烟囱型架构，烟囱型架构并非一无是处，在早期业务死活未知的情况下，不过度设计架构，能直接有效的支持到业务。谁手头没有死过几个业务呢？还记得我们团队有一个产品叫心愿单，刚刚上线就开始做2期研发，等到2期发布的第三天，组织决定这个产品要close了。那个产品的产品经理是我的好哥们叫邹衍，业务负责人是白鸦，就是现在有赞的创始人兼CEO。
不过，当业务发展起来之后，烟囱越树越多，成长的烦恼就如期而至了。第一个问题是人不够，业务响应慢了下来。我们以一个5人研发团队为例来说明一下这个问题。起初团队一个产品都没有，5个人1个月干出一个简单版本的红包系统；几年之后团队增加到10人，但手头要维护10个系统。那么平均人手一个系统，这时候，又来了2个新业务，团队派出3个人去干，大约要干4个月，严重不符合前端业务的响应预期。第二个问题是重复建设，同类烟囱系统中80%的功能是类似的，从数据库模型到主要业务逻辑，都是copy-paste加补丁，一步留神又踩到一个坑。第三个问题是维护成本高。日常升级包、咨询支持服务，团队疲惫不堪。基于此，80%甚至90%的共性问题，能不能抽象出来呢？核心领域模型是否可以是稳定的呢？从下图可以看出，这是可以做到的。
在既要支持不断出现的各种业务，又要建设新平台的纠结权衡之后，我们启动了卡券平台化项目。建设路径是存量业务继续使用烟囱架构，但新业务随着新平台一起接入。第二步逐步迁移存量业务，实现烟囱系统的下线。如下图所示，卡券平台对前端业务提供统一的能力露出，由能力组装编排内部服务。研发规则运营、统一后台管理服务等。
总结下来，平台化架构有以下好处，1是快速支撑、响应业务。2是抽象共性，边界清晰。快速支撑，响应业务是以终为始的出发点。架构如果不服务业务，再高大上都是扯淡。技术不是炫技，要服务商业。再谈谈抽象共性的问题，业务平台化要解决业务共性问题，比如天猫、淘宝都有各类营销活动。那么就抽象出一个营销平台来管理营销活动、营销工具的整个的生命周期管理。并提供给前端业务使用。
从组织层面，平台化会进行业务分治及归口管理，营销平台有对应的技术团队、产品团队和业务运营方。前端业务有需求发生的时候，有对应的受理和决策流程。
平台化之后，按理说万事大吉了。但是又有新的问题出现。以电商平台为例，支付、会员、营销、产品都形成了对应的共享服务，但是对于一个新的前端业务，它要去理解各平台共享服务的职责，并协同，则并非易事。如果还涉及安全、合规、核算等，则涉及的团队更多。那么就有一个问题，已经搭了淘宝、天猫，要做聚划算需要多少人月？要做天猫国际需要多少人月？平台化的架构是尽量的走向了“各人自扫门前雪”，但对于创新的支持力度不足。互联网业务随时在试错，一些创新业务方期望是1-2周的期望上线，平台化发展动辄数月严重不能满足这样的诉求。
我们不妨去回顾那些在无数次发生过的似曾相识的场景，如下图所示：
一个线下支付的需求在对应研发团队是排期1周、研发2周，目标期望1个月完成上线。涉及到支付、金融交换、产品、风控等各团队，虽然都是1-2周的研发，但是实际整体上线可能是2个月。其间假使涉及到20个system，按最小单位1个system 1个开发1个测试算，涉及到40个人员的沟通复杂度，还没有算可能的运营人员，产品经理。同时在系统测试、联调阶段如果还遭遇若干环境问题，其效率可想而知。
总结，平台化架构由于缺乏对于前端业务一以贯之的端到端的支撑能力，平台与平台之间随时存在gap。平台化架构按照康威定律，必然是几个平台，几个团队，涉及到巨大的沟通成本而导致协作困难。平台化架构在数据化运营上存在短板，往往需要把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值。
马老师参观一个著名的游戏公司Supercell之后提出了中台思想，简言之就是“小前台、大中台”。 Supercell从表象看有200多名员工，一个游戏通常4-5个人研发，截止到2016年3月，Supercell面向全球市场推出了《部落冲突》、《卡通农场》、《海岛奇兵》和《皇室战争》四款游戏。大致可以分析Supercell采用的策略：
必须容忍很多失败：比如一个新项目在测试之前，团队就要设定一个指标，比如玩家留存、参与度，我们把这个目标告诉全公司的人，游戏进入测试之后，如果达不到指标，它就会被取消。
快速尝试：曾经在两年内，他们只发布了一款游戏《皇室战争》，但期间取消了9个项目，和若干很多优秀的创意原型。
招聘足够优秀的人：采用倒三角的模式组织团队，一个游戏公司等于若干创业小团队，小团队可以决定做什么，但没达成目标就必须中止。这决定了团队的每一个人是足够super的cell。
Supercell由于其游戏业务的特点，或与其它业务的研发模式不同。但有一个共同性思考，就是一个良好的中台首要的支持前台业务的快速创新。几个人干1-2个月，业务可以close，不用心疼。但如果百人月的产品，试错成本太高，时间方向也不满足高速变化的市场需要。
类比美军作战模式，就可进一步感受中台的作用。美军在二战时期，以军为单位作战；越战时变成以营为单位作战；中东战争时期进化为7人或11人的极小班排作战。之所以美军的“小前端”如此灵活，因为有强大的中台能力，给前端军队提供各种资源支持以及中台炮火群支持打击。
From：陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》图2-4 战场中的中台阵型
前情提要
平台化架构由于缺乏对于前端业务一以贯之的端到端的支撑能力，平台与平台之间存在gap。平台化架构按照康威定律，必然是几个平台，几个团队，涉及到巨大的沟通成本而导致协作困难。平台化架构在数据化运营上存在短板，往往需要把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值。
马老师参观一个著名的游戏公司Supercell之后提出了中台思想，简言之就是“小前台、大中台”。 Supercell从表象看有200多名员工，一个游戏通常4-5个人研发，截止到2016年3月，Supercell面向全球市场推出了《部落冲突》、《卡通农场》、《海岛奇兵》和《皇室战争》四款游戏。大致可以分析Supercell采用的策略：
必须容忍很多失败：比如一个新项目在测试之前，团队就要设定一个指标，比如玩家留存、参与度，我们把这个目标告诉全公司的人，游戏进入测试之后，如果达不到指标，它就会被取消。
快速尝试：曾经在两年内，他们只发布了一款游戏《皇室战争》，但期间取消了9个项目，和若干很多优秀的创意原型。
招聘足够优秀的人：采用倒三角的模式组织团队，一个游戏公司等于若干创业小团队，小团队可以决定做什么，但没达成目标就必须中止。这决定了团队的每一个人是足够super的cell。
Supercell由于其游戏业务的特点，或与其它业务的研发模式不同。但有一个共同性思考，就是一个良好的中台首要的支持前台业务的快速创新。几个人干1-2个月，业务可以close，不用心疼。但如果百人月的产品，试错成本太高，时间方向也不满足高速变化的市场需要。
类比美军作战模式，就可进一步感受中台的作用。美军在二战时期，以军为单位作战；越战时变成以营为单位作战；中东战争时期进化为7人或11人的极小班排作战。之所以美军的“小前端”如此灵活，因为有强大的中台能力，给前端军队提供各种资源支持以及中台炮火群支持打击。
From：陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》图2-4 战场中的中台阵型
我理解，中台不是凭空而来，亦不是平台化架构换个名字。中台化架构是平台化架构的自然演进。一定规模的互联网IT公司都可能有一个叫共享平台或者平台技术这样的部门，就是把业务基础设施和技术基础设施下沉，然后由对应的研发和产品部门去负责。但久而久之，共享平台就成了资源中心，前端业务找你就是要人干活，平台做的也是接客干活。如前文所述，各平台接客模式协同负责度高，周期长。一个商业系统不仅仅是组织几个component，而是需要解决方案。中台提供的能力可以是service、可以是由service组合的组合能力、亦可以是解决方案(solution)的直接输出。
前面提到平台化目标是高内聚、低耦合；职责边界清晰；易于集成等。那么中台化架构进一步可总结为：高内聚、低耦合；数据完整性原则；业务可运营原则。当然，从架构方法来讲，宜采用渐进式架构的演进原则。如果一个中台把若干平台聚拢起来，对业务支持的SLA没有变化、也没有在业务运营上有所改变，一定是失败的。
以上图为例，业务在发展过程中，会有若干业务系统。平台化的架构是按项目模式，把公共平台和业务系统的架构师，开发，测试，产品搞在一起协同、排期、研发、上线。中台化架构可以在进一步把平台能力按能力、服务、实体进行管理。把平台划分为系统运行、业务运营2部分。实现80% 甚至更多的业务需求由业务团队自助进入。这反映到前端业务上支持效能提升了，中台的代码基本不用研发，沟通成本也急剧下降。其2，中台的架构师和研发队伍可以把精力放到中台能力提升，从运营视角发掘类似业务全息查询、数据产品这样的创新。
电商中台的负责人玄难提到：我们讲整个淘宝最早是一个系统搞定，后来不行，必须分拆，用分布式架构，后来每个系统又很复杂了。阿里的生态太大了之后，其实每个人进来已经不知道阿里有什么了，所以必须通过中台把我们有什么能力要呈现出来，让业务方根据自己的需要去选择去使用。同时，我们在架构上能让业务方在这些能力上可以自己去定制，组装成自己的业务。当前的问题通过中台的思路去解决，慢慢这个矛盾就会变低，但必然会产生新的矛盾，就需要用新的思想去解决。
同时，电商业务中台，有四件事情肯定要去做：
第一，保证阿里的业务跑得更快，更稳定。比如保障双十一稳定，同时不断提升前台业务的开发效率。
第二，产生创新。有三种形式，一种是我们看到了某个业务模式比较好，我们会把它变成一种基础能力，提供给更多业务方用；第二种是打通业务之间的连接，例如把阿里生态中A业务和B业务连接，提供给客户新的价值；第三种是通过自己的思考形成新的产品能力，就像前面提到的「地动仪」。
第三，根据集团的需要进行新业务孵化。孵化到一定阶段，觉得可以独立发展的，我们分拆出去，就像我们现在重点投入的海外市场。
第四，人才的培养。在中台，我们能看到集团所有的业务，同时也支撑所有的前台业务，相对来说系统性思考，全局性思考会更好一些。所以，我们也会根据需要给前台业务培养和输出人才。
实现中台有不同的方法和实施路径，但可以总结出类似的目标和价值。
赋予业务快速创新和试错能力
打造数字化运营能力
改变组织阵型带来组织效能提升
有人讲，是否是足够庞大的组织才需要中台思想呢？我觉得不尽然。先说庞大的，曾经淘宝使用近百人、几个月的浴血奋战搞了一个统一的CRM平台。但是大部分商家并不买账，最后这个系统下线了。因为淘宝的几百万商家划分不同行业，规模也有很大差异，不可能靠一套系统解决。后面淘宝通过开放生态建设，把消费者服务、商家IT服务、商家运营服务做了分类，依托15万家ISV来搞定几百万家商家不同需求。按我的理解，这就是中台化实践，通过开放赋予不同业务，不同商家业务创新的机会。同时通过一系列运营服务比如数据分析工具促进了商家业务量的变化，是运营赋能业务的体现。
第2个case，来自转瞬之夏《一次交易失败引发的血案和思考》。故事大概是这样的：
任何一个合格的产品负责人，都会具有一个特点，就是喜欢使用、捣腾自己的产品以及同行的产品。就拿今天来说，抱着思考产品特性和探究异常处理逻辑的想法，我故意在收银台签约并支付时，输错3次短信验证码，果不其然，在点击支付时，系统报交易存在风险，交易失败。
一切都和预期一致，于是我想，简单测试完了，估计是触发了风控规则，，找客服帮我解锁吧。但想了想，正好可以验证下这种输错验证码被拦截的常见场景，客服处理起来效率怎么样。
于是我找了在线客服，然后角色扮演一位不小心输错验证码而被锁的可怜顾客，并只提供少量信息。我本以为是很简单就能定位的事，所以也估计客服也能很快就能解决。但实际情况是，客服给了我一个完全错误的解决方案，而且把出现异常的原因认定为我输错了银行预留手机号导致的。
......
作者提出的关注客户，关注客服，关注体验的观点，我很认同。但这个问题具备普遍性，想站在中台的角度多说几句。站在平台化思考问题，对于你的服务对象，可能是割裂的。
平台化的协作可能是这样的，YY一张图：
从上图可以看到，用户可能在做某项业务比如购买的时候到收银台；他没有正确完成签约；触发了风控规则。那么一般而言，如果客服是人肉服务模式的话，通过知识库查询对应问题的答案告知客户，或者找产品，产品找开发，开发找安全团队的开发或产品，进行一系列讨论，最终给出答案。
回顾一下，我前面提出的平台化思路的不足，平台职责明晰，但如果站在用户（商户）服务和支持的视角，就全然不是那么回事了，用户对了解内部职责的划分没有兴趣。他们只想快速，准确的给我解释，告诉我怎么做。
那么，我们把接触客户的部分当作客户服务中台，把共享服务当作共享业务中台，前端Bu业务作为xx业务中台。这些中台之间需要按照服务对象来梳理能力，并互相协同。
如上图所示，业务共享中台和业务中台的业务产品上下线、对客可见的规则变更类需要联动到服务中台的知识库、help页面。而服务中台运营对产品分析，产品改进提出反馈。业务共享中台拥有全部的基础数据和系统链路资产，可以提供用户画像数据、业务全息查询等工具给服务中台。有此可见，多个中台互为消费关系，虽然各中台职责分明，但如何更好的服务业务，服务用户，提升企业运营能力甚至支持产品创新都是最基础的原则。
总结：平台化相比于烟囱型架构基于提升效能，消除重复，职责聚焦的视角而来；而中台化是平台化的自然演进，以进一步通过改变组织阵型提升效能、数据化运营、更好支持业务发展和创新。任何应用架构、组织架构都没有终点，只有“合适”。当非关键冲突变成关键冲突的时候，又是新一代架构要持续升级的时候了！
QA：
Q：银行的组织架构也划分了前台、中台、后台。 前台通常是以客户为中心，和客户直接打交道的岗位；中台一般不直接接触客户，但要负责制定业务策略、风险控制等；后台主要是业务的处理和支持。 前中后台分离后，通过流程银行来支持业务运营，建立呼叫中心、单证中心、集中作业中心等，提高效率降低成本、降低人员要求，让专业的人做专业的事情。 IT架构为适应业务架构，通常也是划分了前台、中台、后台系统。 而基础的技术支撑平台则是共享的，如开发工具、开发框架、运行平台、基础设施（云服务、中间件）、基础组件（认证、安全、通讯、加密、审计等）。 等）。那么这里的中台化是不是就是银行组织结构的中台？
A：
我觉得不尽然。不同平台无论在业务的组织形态还是上下游关系上有”前台”、“中台”、“后台”的分野，但如果是分离提供服务支持业务的模式，那么就没进化到中台模式。中台模式可以构建解决方案能力，快速支持业务，消除平台之间的gap、通过组织变革配套促进创新。传统的前台业务比如to C的客户接触、受理也可以升级中台思维。能不能做全渠道打通？能不能提升用户体验、精准服务用户？等等，跳出柜台受理、网银受理的界限和框框，全渠道全业务，或有更好的用户黏性也未可知。
参考材料：
简书：转瞬之夏的日记本（http://www.jianshu.com/p/5207680ea08c）
阿里研究员玄难：如何做电商中台
淘宝和天猫背后，阿里系还有一个不为人知的神秘组织
陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
云栖社区：平台化三部曲之一微核心可扩展架构 - 从Eclipse平台看交易平台化
标签：良好的 客户 实现 联动 back 战略 为我 环境 ice
原文地址：https://www.cnblogs.com/xuwc/p/14100442.html
