现代企业架构框架白皮书

现数架字化转构型底层方白法论业皮书 目录 1.引言：再提“业务平台化”4 1.1“中台”概念的提出、流行到深水区实践， 折射出本轮数字化转型中以“业务平台化”为代表的企业现代化趋势5 1.2再提业务平台化，是因为深水区实践中， 新的问题将业务平台化内涵向前演进8 1.3企业架构设计方法，是有效的工作方法， 经典的企业架构框架已不足够应对业务平台化中的新问题11 1.4ThoughtWorks在经典企业架构框架基础上， 面向以业务平台化为代表的企业现代化转型中的新问题，发布现代企业架构框架13 2.现代企业架构框架（ModernEnterprise ArchitectureFramework-MEAF）14 2.1企业架构15 2.2企业架构框架15 2.3现代企业架构框架16 2.4现代企业架构框架设计原则17 2.5现代企业架构框架元模型总览18 3.现代企业架构框架—业务架构20 3.1业务架构元模型综述20 3.2业务架构元模型应用22 3.3业务架构元模型补充说明39 4.现代企业架构框架—应用架构42 4.1应用架构元模型综述43 4.2应用架构元模型应用43 5.现代企业架构框架—数据架构52 5.1数据架构元模型综述53 5.2数据架构元模型应用53 6.现代企业架构框架—技术架构58 6.1技术架构元模型综述59 6.2技术架构元模型应用59 7.总结68 8.参考文献 -----------------------------------------------69 1 引再平台提化：“业”务 2020年是“黑天鹅”集中爆发的一年，也是数字化新一波浪潮涌起的一年。数字化转型的声浪正在以加速的态势进入到各行业、各企业的战略主航道。以数字化的方式对于业务进行创新与重塑，正在成为企业新的发力点和主战场。 多项研究调查显示，60%以上的受访高管们(参考文献1、2)，在疫情之后，都充分意识到数字化的必要性和对于企业带来的机遇，并表示正在着手加速企业的数字化步伐。而疫情期间，快速拥抱数字化的组织，所展现的绩效水平在其所在行业的横向对比中，也均显著优于竞争对手（参考文献2）。 本轮以数字化驱动业务创新与重塑，越来越清晰的聚焦于：数字体验、业务平台化、智能化与云三大领域。尽管不同的行业、组织和企业，对上述领域的表述和内涵界定可能会存有差异，或仍有其他特定领域的特征显现，但在我们的观察中，这三大领域，已在跨行业范围内形成了较为广泛的共识。 本白皮书将首先聚焦于“现代企业—业务平台化”的趋势。我们再提“业务平台化”，源于我们在不同的行业和企业当中，反复观察和接触到、并致力于帮助解决的一系列新问题，这些问题背后所体现的趋势和解决的思路与方法，将赋予现代企业新的内涵。 “中台”概念的提出、流行到深水区实践， 1.1 折表射的出企本业轮现数代字化化趋转势型中以“业务平台化”为代 1）以互联网巨头中台化为原点，延伸到以零售、金融、电信为代表的传统行业数字化建设，中台实践正在进入到深水区 从2015年开始，以阿里巴巴为代表的各互联网巨头，陆续开启中台化进程（如图1）。随后，“中台”理念和相关实践开始快速向各行业渗透和发展。 零售行业 得益于阿里在零售行业的渗透和影响，以及电商在过去十年的高速发展，零售行业最先试水“中台”。一方面，阿里本身将中台理念与实践结合云服务向各行业输出，同时零售行业因业务模式的相似性， 也具备较好的适配基础。另一方面，围绕电商业务模式，一系列厂商将其中标准化程度较高的部分快速“中心化”，如“商品中心”，“订单中心”，“支付中心”等，以“中台”的形态进行实施，也在一定程度上促进了中台在零售行业的推广。而零售行业的中台模型，因其本质是对于交易合同及履约的业务抽象，具备较广的适用性，也常被其他行业借鉴和扩展。 金融行业 对于金融行业，打造中台能力，无论在银行、证券或是保险等细分行业，均已是高度共识的战略举措 公司 时间 中台相关事件 阿里巴巴 2015年12月 宣布全面启动“中台战略，构建符合大数据时代的“大中台、小前台”组织机制和业务机制 腾讯 2018年9月 组织架构调整，“扎根消费互联网，拥抱产业互联网”，在技术上开源节流，自研上云，全面建设中台 美团 2018年11月 尝试打通各个业务之间的数据，实现用户端的账户统一，实现用户数据中台 京东 2018年12月 发布组织调整，采用“中台”的组织概念，中台部门已TOB为主，包括3C电子及消费品零售事业群、时尚居家平台事业群、生活服务事业群、技术中台和数据中台、商城用户体验设计部、商城市场部等六个核心部门 字节跳动 2019年3月 搭建“直播大中台”，“直播大中台”将抖音、西瓜视频和火山小视频三个短视频产品抽出、 合并，支撑字节跳动旗下的所有直播业务资料来源：腾讯科技、公司公告，中银国际证券 (图1.1-1互联网企业的中台化大事件)（参考文献3） 之一。（参考文献4、5）当行业越来越重视客户一致性体验，开始打造开放银行，深度运营客户，构建生态的同时，对于长期掣肘金融行业发展的历史遗留问题，企业也深刻意识到对于此类问题解决的迫切性。如庞大的遗留系统难以响应前端快速的业务创新、客户和业务数据孤岛现象严重、组织架构壁垒高筑等。而中台建设被认为是行业普遍认同的求解之道，根据恒生调研，半数金融机构正在考虑建设业务中台，90%金融机构认为未来两至三年会建设业务中台。（参考文献4、5） 电信行业 以IT基础设施作为重要支柱的电信行业，始终保持对IT新技术与工程实践的关注和引入。过去5年，伴随通信技术的快速换代所带来的新的市场特征，围绕业务响应力提升和研发效能改进的目标，电信行业IT基础设施经历了新一轮的翻新和升级：研发体系的敏捷转型，DevOps体系搭建、大型核心系统的容器化及服务化改造。在此基础上，加之“新基建”顶层设计的牵引和推动，行业整体的IT基础设施进一步深化，中台建设作为突破点和抓手之一，在营销、服务、网运等多层面展开，并不断取得进展。 2）ThoughtWorks在以上行业中台建设的深入实践认为，“中台”不是目的，而是手段，“平台化”向业务的再演进，是本轮数字化建设中的重要趋势 回顾ThoughtWorks对于中台的实践，我们持续向行业输出一系列思考和洞见的同时，也广泛且深入 参与了各行业的数字化建设中、尤其是以上三大行业中领跑企业的中台建设过程。 在我们的经验中，不同的行业，中台有着不同的最佳适配领域，这里从前面提到的三大行业中，我们列举一些各自领域关注的方向： •零售多品牌集团型企业：关注如何通过中台建设，实现集中管控前提下营销能力在多品牌复用 •跨国零售企业：关注如何通过中台建设，实现全球统一运营下的核心业务能力针对中国市场的复用与差异化适配，以适应中国的特有业务场景和业务发展 •商业银行与金融机构：关注在特定业务（如信贷、资管）场景的能力抽取与模式复用，实现对于金融产品的快速创新的加速，和金融电商化的渠道能力运营的加强，为生态建设奠定基础 •通信企业：关注如何实现跨业务线之间的公共能力的识别，沉淀，形成统一管控及支撑，实现产品平台化，更灵活的适配不同场景的需求与快速响应。 这些领域中，中台的差异化适配和建设，印证了中台实践已进入深水区。 而与此同时，中台实施“失败”的案例也不绝于耳，行业对“中台”观点，出现清晰的分化。这里，我们不展开对于中台实施失败案例的讨论与分析，而将关注点放在更加底层的商业逻辑和方法论沉淀上来。 在我们看来，中台建设的成功，或者“失败”，甚至“去中台化”声音背后，本质上是一致的商业逻辑： 中是”台广建义设“软件不 套件实施： 中台建设业“是” 模深度式分端析到、端建的模 与复用： 中台以“复用”之名起源，因此，一些案例中，很容易走回从前软件套件实施的思路，以“套件化”的模式，加上一定程度的开放和定制，实现“复制”。“复制”、“复用”一字之差，却意味着从规划到落地截然不同的方法和实现。由此带来的问题是，曾经套件化实施过程中围绕“削足适履”出现过的问题、走过的弯路，在中台规划与建设中，如果仍以“中台产品套件”实施方式，会不可避免的再次出现。 中台究竟在复用什么？我们给出的答案是：中台是针对于“商业模式”和“业务模式”的抽象与复用。背后体现的是企业希望通过对于自身商业模式的不断思考与认知，再通过自身业务模式的抽象与沉淀，实现跨地域、跨用户、跨场景、跨领域的扩展与复用，支撑企业业务的快速拓展与创新，也体现和契合了平台向业务的再演进过程。 借用我们一位咨询师的话：“看上去的能力复用是乐高组装，但真实的能力复用其实是器官移植，需要的是一场外科手术。” 因此，我们认同这样的观点：“中台”是手段、过程，不是目的本身。回归本源，从问题与价值出发，“平台化”向业务的再演进，是这一轮数字化建设浪潮中需要关注的重要趋势，也是企业现代化进程中的关键步骤。 新的问题将业务平台化内涵向前演进 1.2再提业务平台化，是因为深水区实践中， “平台化”是从信息化到数字化时代，每一轮IT建设都会提及的主题之一。而当平台沿着历史发展的趋势继续向业务的“逼近”过程中，对于平台抽象和建设的难度也成指数型增加，涌现出了一系列新问题。 对于这些问题的思考和解决方案的探索，也将赋予业务平台化这个趋势以新的内涵和意义，同时也是我们设计和发布新的企业架构框架的起心动念。这些问题的“新”意，更多的体现在“how”上，而不再仅仅是“what”，所以我们以“如何”的句式来逐一总结和简述： 1）如何抽离多业务线共享的解决方案和能力，集中管控和演进，以避免重复投资？新业务如何基于企业已有的解决方案和能力快速组装上线，以支撑业务快速迭代创新？ 今天，业务发展和IT建设的绑定比以往任何时间都更加紧密，而当大型企业的业务涉猎已足够广泛，多条业务线、或者多个业务单元并行发展，IT建设会随着业务边界、组织边界，不可避免的进一步分化，也加剧了IT部门进行统一管控的困难。 一方面，在很多场景中，这样的分化带来了双重投资甚至多重投资的浪费；另一方面也在加剧本就存 在的用户或者客户体验的割裂、数据孤岛、IT翻新周期长等固有问题。 同时，当业务线不断尝试新的业务模式，或对于已有模式进行更快的试验、调整与扩展。对于IT支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景应对下，成本高昂。 因此，如何抽离多业务线共享的解决方案和能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？是需要解决问题。进一步拆解，我们认为需要回答： •针对不同的业务深度，如何设计“模式”与“能力”模型，以对业务进行合理的抽象，进而识别相似度，抽象与提炼可复用的业务模式；而针对不同业务的差异性，如何在“模式”和“能力”基础上进行扩展？ •抽象并沉淀了业务能力之后，如何在新的业务场景中，识别、复用已有能力，应用、数据、技术及组织应该如何予以支撑？ •以上的工作过程，是否有较好的工作实践和参考模型？ 2）如何合理地划分IT系统边界，以得到随“需”而变的响应力 除了能力复用外，另一个提升IT支撑响应力的关键是，提升IT系统各组成部分的自治性，使得变更能够相对独立的，在更小的边界范围内，以小步快跑的方式发生，同时还需要保持一定的一致性，使整体架构做到“形散神聚”。 因为无论是创新也好，集中管控也好，虽然变化速率不同，但变化始终存在，既然变化不可避免，我们应将精力投入到应对变化上。而一个清晰的应用边界划分，可以对于业务能力通过对于知识边界的解耦，实现知识的黑盒复用，对于变化的响应非常有帮助。 在我们的经验中，应用边界划分不合理会对应对变化产生明显的负面作用。一般来说，边界的粒度过粗，容易产生功能、运行层面的变更冲突，而边界的粒度过细，则带来了额外的变更成本和性能开销，这里对各种负面作用暂不作展开，但它们的共同点是都会拖