共计 6487 个字符，预计需要花费 17 分钟才能阅读完成。
2020 年，受到“黑天鹅”事件的影响，数字化减速进入各行业、企业的策略主航道。通过数字化进行业务重塑和翻新，成为企业新的发力点和主战场。ThoughtWorks 作为一家数字原生型征询公司，在宽泛的实际中，洞察出“业务平台化”再次成为企业数字化建设中的要害畛域之一。
一、中台催生出新一轮数字化建设中“业务平台化”的趋势
1.1 互联网巨头中台化辐射到批发、金融、电信等传统行业，中台实际进入深水区
从 2015 年开始，以阿里巴巴为代表的互联网巨头们，陆续开启中台化过程（如图 1）。随后，中台理念和实际开始疾速向各行业浸透。
（图 1 互联网企业的中台化大事件（参考文献 1））
- 批发行业
得益于阿里在批发行业的浸透和影响，及电商在过来十年的深度倒退，批发行业最先试水中台。一方面，阿里将中台实际联合云服务向各行业输入，批发行业因业务模式的相似性，从而有较好的适配根底。另一方面，围绕电商业务模式，一系列厂商将其中标准化程度较高的局部疾速“中心化”，如“商品核心”，“订单核心”，“领取核心”等，以中台的状态进行施行，也在肯定水平上促成了中台在批发行业的推广。而批发行业的中台模型，因其本质是对于交易合同及履约的业务形象，具备较广的适用性，也经常被其余行业借鉴和扩大。
- 金融行业
金融行业中对于中台能力的打造，无论在银行、证券或是保险等细分行业，均已是策略动作之一（参考文献 2、3）。当行业越来越器重客户一致性体验，开始打造凋谢银行并深度经营客户，长期以来掣肘金融行业倒退的历史遗留问题的解决已火烧眉毛，如宏大的遗留零碎难以响应前端疾速的业务翻新、客户和业务数据孤岛、组织架构壁垒等，中台建设是行业广泛认同的求解之道。依据恒生调研，半数金融机构正在思考建设业务中台，90% 金融机构认为将来两至三年会建设业务中台。（参考文献 2、3）
- 电信行业
以 IT 基础设施作为重要支柱的电信行业，始终保持对 IT 新技术与工程实际的关注和引入。过来 5 年，随同通信技术的疾速换代所带来的新的市场特色，围绕业务响应力晋升和研发效力改良，电信行业 IT 基础设施经验了新一轮的翻新和降级：研发体系的麻利转型、DevOps 体系搭建、大型外围零碎的容器化及服务化革新。而在“新基建”顶层设计的加持下，行业整体的 IT 基础设施进一步深入，中台建设作为突破点和抓手之一，在营销、服务、网运等多层面开展，并一直获得停顿。
1.2 中台不是目标而是伎俩，实质是“平台化”再向业务演进
回顾 ThoughtWorks 对于中台的摸索，咱们继续向行业输入一系列思考和洞见的同时，也宽泛且深刻参加到各行业领跑者、尤其是以上三大行业的中台建设过程中。
在咱们的教训中，中台之于不同的行业，有着不同的最佳适配畛域，这里咱们从后面提到的三大行业中列举一些：
- 批发多品牌集团型企业：通过中台建设，实现集中管控前提下营销能力在多品牌复用。
- 跨国批发企业：通过中台建设，实现寰球对立经营下的外围业务能力针对中国市场的复用与差异化适配，以适应中国特有的业务场景和业务倒退。
- 商业银行与金融机构：在特定业务 (如信贷、资管) 场景下的能力抽取与模式复用，实现对于金融产品翻新的减速，及金融电商化渠道能力经营的增强，为生态建设奠定根底。
- 通信企业：跨业务线之间的公共能力的辨认、积淀，造成对立管控及撑持，实现产品平台化，更灵便地适配不同场景的需要与疾速响应。
这些畛域中，中台的差异化适配和建设，印证了中台实际已进入深水区。
而与此同时，行业中中台施行“失败”的案例也不绝于耳，以至行业中对中台的观点，呈现清晰的分化。这里，咱们将不开展中台施行失败案例的探讨，也并不是要在不同观点中做出抉择。
在咱们看来，中台建设的胜利，或者失败，甚至“去中台化”声音背地，实质上是统一的商业逻辑：
- 中台建设不是狭义软件套件施行。中台以“复用”之名起源，因而，一些案例中，很容易走回从前软件套件施行的思路，中台以“产品化”、“套件化”的模式，加上肯定水平的凋谢和定制，实现“复制”。“复制”、“复用”一字之差，却意味着从布局到落地截然不同的办法和实现。由此这带来的问题是，已经软件套件施行过程中因“削足适履”呈现过的问题、走过的弯路，在中台“套件”施行过程中，会不可避免的再一次呈现。
- 中台建设是对于企业业务模式端到端的深度剖析、建模与复用。中台到底在复用什么? 咱们给出的答案是: 中台是针对于“商业模式”和“业务模式”的形象与复用。背地体现的是企业心愿通过对于本身商业模式的 一直思考与认知，再通过本身业务模式的形象与积淀，实现跨地区、跨用户、跨场景、跨畛域的扩大与复用，撑持企业业务的疾速拓展与翻新，也体现并符合了平台向业务的再演进过程。
借用咱们一位咨询师的话：“看上去的能力复用是乐高组装，实在的能力复用其实是器官移植，须要的是一场外科手术。”
因而，咱们认为且认同这样的观点，中台自身是伎俩、过程，不是目标。回归根源，其本质是“平台化”再一次向业务演进。
二、新问题将业务平台化外延向前演进
从信息化到数字化，是“平台化”每一轮 IT 建设都会提及的主题之一。而当平台沿着历史倒退的趋势持续向业务的“迫近”的过程中，对于平台形象和建设的难度也成指数型减少，涌现出了一系列新问题。
对于这些问题的思考和解决方案的摸索，也将赋予业务平台化这个趋势以新的外延和意义，同时也是咱们设计和公布新的企业架构框架的起心动念。而这些问题的“新”意，也体现在深水区实际中从“what”向“how”的转变，所以咱们以“如何”的句式来逐个总结和简述：
2.1 如何抽离多业务线共享的能力，集中管控和演进，以防止反复投资？新业务如何基于企业能力疾速组装上线，以撑持业务疾速迭代翻新？
明天，业务倒退和 IT 建设的绑定比以往任何工夫都更加严密，而当大型企业的业务涉猎已足够宽泛，多条业务线、或者多个业务单元并行倒退，IT 建设会不可避免的随着业务边界、组织边界进一步分化，也加剧了 IT 部门进行对立管控的艰难。
一方面，在很多场景中，这样的分化带来双重投资甚至多重投资的节约，另一方面，也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT 翻新周期长等固有问题。
同时，当业务火线一直尝试新的业务模式，或对于已 有模式进行更快的试验、调整与扩大时，对 IT 撑持的响应力也提出了更高的要求。固有的零碎搭建或者产品部署模式，越来越不足以提供及时的响应，且在“疾速试错”、“小步快跑”的翻新场景下，老本昂扬。
因而，如何抽离多业务线共享的能力，集中管控和演进，以防止反复投资？新业务如何基于企业能力疾速组装上线，以撑持业务疾速迭代翻新？成为亟待解决的问题，进一步拆解，咱们认为须要答复：
- 针对不同的业务深度，如何设计“模式”与“能力”模型，以对业务进行正当的形象，进而识 别类似度，形象与提炼可复用的业务模式，而针对不同业务的差异性，如何在“模式”和“能 力”根底上进行扩大?
- 形象并积淀了业务能力之后，如何在新的业务场景中，辨认、复用已有能力，利用、数据、技术及组织应该如何予以撑持?
以上的工作过程，是否有较好的工作实际和参考模型?
2.2 如何正当地划分 IT 零碎边界，以失去随“需”而变的响应力
除了能力复用外，另一个晋升 IT 撑持响应力的要害是，晋升 IT 零碎各组成部分的自治性，使得变动可能绝对独立的、在更小的边界范畴内，以小步快跑的形式产生；同时还须要放弃肯定的一致性，使整体架构做到“形散神聚”。
因为不论是翻新也好，集中管控也好，尽管变动速率不同，但变动始终存在，既然变动不可避免，咱们应将精力投入到应答变动上。而一个清晰的利用 边界划分，能够对于业务能力通过对于常识边界的 解耦，实现常识的黑盒复用，对于变动的响应十分有帮忙。
在咱们的教训中，利用边界划分不合理会以致应答变动产生显著的负面作用。一般来说，边界的粒度过粗，容易产生性能、运行层面的变更抵触，而边界的粒度过细，则带来了额定的变更老本和性能开销，这里对各种负面作用暂不作开展，但它们的共同点是都会拖慢 IT 撑持的响应力或稳定性。
因而，“如何划分 IT 零碎的边界，以正当的布局更好地应答变动”是须要解决的问题。进一步拆解，咱们认为须要答复：
- 如何划分利用构建块的逻辑边界，使其尽可能职责繁多、接口标准明确，容易变更和组装？
- 如何组合利用构建块成为适合粒度的独立可部署单元，尽可能减少性能、运行层面的变更抵触？
- 如何形容、留存以上决策的后果和根据，当变动产生时，通过溯源做出优质的新应答？
2.3 如何适当拆分过于集中的剖析类数据处理职责，以缓解规模化瓶颈？
长久以来，业界对数据架构达成共识是：对于运行类 (Operational) 和剖析类 (Analytical) 场景，应该应用不同的设计办法和技术撑持。
运行类场景以业务事务为主线，关注点在于业务事务运作证据的完整性和一致性，以及确保各类数据在各业务单元间高效、精确地传递，实现跨业务单元的事务推动及对于业务溯源的撑持。
剖析类场景则须要对内、内部数据进行收集和加工，用来度量业务运行体现、尝试剖析产生偏差的起因，甚至给出预测，或者联合机器学习技术得出业余论断。
数据想要造成剖析类价值，背地须要通过摄取（Ingest）- 加工（Process）- 能力包装（Serve）三大工序，其又能够进一步分为数据仓库、数据湖两种设计办法和技术栈，它们有各自不同的实用场景和技术栈，它们的差别咱们暂不作开展。
因为剖析类场景所要求的办法和技术与事务类场景有显著的不同，许多企业组建了专职的数据团队，将剖析类数据处理工作和其背地的复杂性打包成为一个黑盒，提供端到端的数据服务。
这个模式对于业务场景可实用于简略的企业环境，但难以满足多业务线、业务平台化的企业环境。一方面，随着 IT 建设减速，数据源和剖析类场景的数量激增，对数据服务的响应力提出了更高要求。另一方面，想要提供高质量的数据服务，除了剖析类数据的专业技能，还要求对于业务场景、现有应用软件的深刻了解。如果所有工作依然只由专职的集中式团队一肩挑，团队带宽的限度必然会拖慢响应力。
因而，咱们认为须要摸索的是如何适当拆分过于集中的剖析类数据处理职责，为集中式的数据团队减负，使其能够将精力投入到高价值的剖析类场景中。
2.4 如何在富技术时代进行平台型技术架构选型及设计？
受害于云原生架构的衰亡与倒退，新技术的涌现和一直成熟，以及技术工具的极大丰富，技术架构设计的灵便度和效率都失去了显著晋升。
而另一方面，在平台型技术架构的设计中，作为多业务条线、多利用、多数据场景落地的技术基座，技术架构设计所需笼罩的规模、应答的复杂度今非昔比。加之“富”技术条件的加持，一个好的技术架构设计的艰难度实际上指数级减少。始终以来，技术架构设计的办法和过程是强依赖于架构师的教训和能力的，而“富”技术环境让一系列挑战和问题再次凸显：
- 对于架构需要把握有余或者没有架构需要的剖析意识，过早的进入架构设计，导致系统复杂度变高甚至适度设计，为开发落地带来额定的研发老本。
- 架构设计采纳的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和施行成果造成影响。架构设计过程工夫长，实现后团队就不再违心对设计方案持续调整和迭代，当技术倒退变动很快时，技术架构计划容易进入“实现即掉队”的困局。
因而，咱们认为相比以往，架构师们更须要这样一个体系：
- 系统性的剖析架构需要；
- 结构化的设计架构计划；
- 积淀可复用的架构教训。
三、经典的企业架构框架已不足够应答业务平台化中的新问题
3.1 以企业架构框架进行业务平台设计，各支流办法各有偏重
业内越来越广泛的采纳企业架构框架作为业务平台化整体规划领导和办法，这是无效的。因为各类企业架构框架的元模型，大体都能够归结为四类视图，即业务架构，利用架构、数据架构和技术架构，只管不同框架在具体的层级划分、及各层构造下的内容涵盖可能会略有不同。这样的构造较好的匹配业务平台设计的问题域。
同时，各类企业架构框架的工作逻辑类似，均是从愿景与业务指标登程自顶向下的贯通设计，并放弃从业务到技术的一致性，这样的工作逻辑与业务平台从设计到落地的逻辑统一。
在此基础上，不同的企业架构框架，因为产生的背景和倒退过程的不同，造成各自的侧重点或者行业属性，这也从另外一个方面增强了适用性。例如：
- Zachman：偏重从利益相关者的六个视角来形容企业。
- TOGAF：强调企业架构全生命周期治理。
- DoDAF/FEAF-II：面向政府机构的投资组合治理，重视 ViewPoint。
- BIAN: 面向银行业，有银行业开箱即用参考模型。
须要阐明的是，以上的偏重总结，仅代表咱们在我的项目操作中的了解，实际上，每一种框架都是齐备的，在各自的畛域和实用场景中也失去宽泛的利用。
3.2 经典框架对业务平台化的新问题没有特定的设计和思考
上面这张表格，体系化的从零碎的概念、建模、流程的角度，对若干经典企业架构办法进行比照，从中咱们能够解读出，在 Concept（概念）层面的各项评估中，各框架广泛的评定都在 H（高）和 M（中），而从 Modeling（建模）开始，到 Process（流程），评定开始从 M(中)转向 L（低），其中，和落地的相关性越高的评估项，广泛的评定都位于 L（低）。
（图 2 企业架构框架比照 参考文献 4）
这张表格出自 2015 年（参考文献 4），在这之后的 5 年工夫里，各框架均不同水平对实操内容进行了补充和加强。但从咱们的跟进钻研和我的项目教训来看，各经典框架在我的项目工程实操性中仍显有余。这可能也与经典框架的定位相干，大都定位于战略规划和组织治理，对于架构的具体设计和建模层面都没有细粒度开展。
同时，在第二大节中所提及的，业务平台化趋势下咱们所面临的新问题，能够较好的映射进企业架构框架元模型的四个档次中：
- 业务架构层：如何抽离多业务线共享的能力，以防止反复投资？新业务如何基于企业能力疾速组装上线，以撑持业务疾速迭代翻新？
- 利用架构层：在宏观布局层面，如何划分 IT 零碎的物理边界，以正当的布局更好地应答变动，在部分设计层面，如何在最大化复用成果的同时，保障对差异化需要的响应力？
- 数据架构层：如何适当拆分过于集中的剖析类数据处理职责，缓解规模化瓶颈？
- 技术架构层：如何在富技术时代进行平台型技术架构设计？
而这些问题，从各经典企业架构框架中很难间接找到针对性的设计参考和考量根据，须要咱们进一步思考、实际与提炼。
参考文献：
- 参考文献 1：《从技术走向商业看中台 投资机会》中银国际证券
- 参考文献 2：《中国行业趋势报告 -2020 年度特地报告》罗兰贝格
- 参考文献 3：2019 恒生电子技术开放日
- 参考文献 4：A Framework for Evaluation of Enterprise World Academy of Science, Babak Darvish Rouhani, Mohd Naz’ri Mahrin, Fatemeh Nikpay, Maryam Khanian Najafabadi, Pourya Nikfard，Engineering and Technology International Journal of Economics and Management Engineering Vol:9, No:1, 2015
起源：ThoughtWorks 洞见
作者：ThoughtWorks
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
7 月每周四晚 8 点，【冬哥有话说】研发效力工具专场，公众号留言“效力”可获取地址
- 7 月 8 日，LEANSOFT- 周文洋《微软 DevOps 工具链的 “ 爱恨情仇 ”（Azure DevOps）》
- 7 月 15 日，阿里云智能高级产品专家 - 陈逊《复杂型研发合作模式下的效力晋升实际》
- 7 月 22 日，极狐 (GitLab) 解决⽅案架构师 - 张扬分享《基础设施即代码的⾃动化测试摸索》
- 7 月 29 日，字节跳动产品经理 - 胡贤彬分享《自动化测试，如何做到「攻防兼备」？》
- 8 月 5 日，声网 AgoraCICD System 负责人 - 王志分享《从 0 到 1 打造软件交付质量保证的闭环》