目录

1. 引言：再提“业务平台化”

1. “中台”概念的提出、流行到深水区实践，折射出本轮数字化转型中以“业务平台化”为代表的企业现在花趋势

2. 再提业务平台化，是因为深水区实践中，新的问题将业务平台化内涵向前演进

3. 企业架构设计方法，是有效的工作方法，经典的企业架构框架已不足够应对业务平台化中的新问题

4. ThoughtWorks在经典企业架构框架基础上，面向以业务平台化为代表的企业现代化转型中的新问题，发布现在企业架构框架

2. 现在企业架构框架（Modern Enterprise Architecure Framework - MEAF）

1. 企业架构

2. 企业架构框架

3. 现代企业架构框架

4. 现代企业架构框架设计原则

5. 现代企业架构框架元模型总览

优质的资源

周五晚上便便太硬，最后出血了。搞不清楚是痔疮还是肠炎，打算去看看。先去了距离比较近的深圳天元中医肛肠医院。想着名字起的专业对口。

进门问走医保还是自费。医保挂号费11，自费2元,虽然没搞懂为啥差距这么大，还是选择了医保。然后有护士领着去到一个老医生办公室。居然不需要叫号排队。问了没2句就说要具体检查下。要做肛门镜和指检。

走进检查室居然有3个女护士，我心思用的着这么多嘛。然后老医生就硬怼(疼)，让我看前面的屏幕，说这是你的肠内影像。这里xxx, 你看前面还有出血，不一定是痔疮。期间说话我没听懂，反问几句都是旁边的护士答的。怪不得需要这么多护士。然后就让我先出来，他们等下叫我。

没一会儿叫我进去，桌子上放着一个人体大肠模型。说有痔疮，但里面还有血，还需要进一步检查。我心说有打算做个肠镜。但听他们的说法现在就可以做。我说不是需要准备几天排泄啥的，他们说半肠镜不需要。我说和全肠镜的区别是啥。都是旁边的护士在回答，去北大医院挂专家号也没遇到过这样的护士。最终大概意思是半肠镜不需要清理肠胃，价格和全肠镜一样。然后递给我报告，我一看不对吧，年龄就不对。主诉1年？我不是说的昨天出现的嘛。整个流程也非常不靠谱，于是打算先走吧。

我说肠镜还是半肠镜我考虑下。那个老医生愣了，啥，你不检查下嘛，不检查没办法定位。我说我先考虑下，你给开点药。然后他准备开一大堆中药。我说麝香膏就行。然后，他们的回答惊呆了我。

旁边的护士说：我这里没有，你出去外面药店买吧，能用医保。

第二天挂了宝安区中心医院，医生年龄不是很大，但是主任了。听我了的遭遇，他蔑视的笑了笑，然后说他检查下。先涂了凡士林啥的，不痛，过程也很快。最后说多喝水，多吃香蕉火龙果，把便便软化就行了，没事多注意提肛。我说不需要肠镜，做手术啥的嘛。他说不需要，先观察一个月软化了再看。给开了消毒的药。完事。

往后，除了正规医院，其他医院大概我再也不会去了。

------------------

信念

看了《独行月球》，电影院的氛围感还是值得一去的，周日晚上去看的话，差不多位置随便选。整个片子感触最新的还是：信念是一切的根源

打印票据居然用的excel

------------------

这一周看一篇资料，ThoughtWorks发布的现代企业框架白皮书，早上上班路上断断续续看完了。但吸收还差的远。我发现他们这个文章用的术语，措辞，讲述方式，都值得学习。当然，最重要的是设计框架看完也觉得很值得学习。先学习，今天抄写了背景和介绍。

1.引言：再提“业务平台化”

2020 年是“黑天鹅”集中爆发的一年，也是数字 化新一波浪潮涌起的一年。数字化转型的声浪正在 以加速的态势进入到各行业、各企业的战略主航道。以数字化的方式对于业务进行创新与重塑，正在成 为企业新的发力点和主战场。

多项研究调查显示，60% 以上的受访高管们 ( 参考 文献 1、2)，在疫情之后，都充分意识到数字化的 必要性和对于企业带来的机遇，并表示正在着手加 速企业的数字化步伐。而疫情期间，快速拥抱数字 化的组织，所展现的绩效水平在其所在行业的横向 对比中，也均显著优于竞争对手（参考文献 2）。本轮以数字化驱动业务创新与重塑，越来越清晰的 聚焦于：数字体验、业务平台化、智能化与云三大 领域。尽管不同的行业、组织和企业，对上述领域 的表述和内涵界定可能会存有差异，或仍有其他特 定领域的特征显现，但在我们的观察中，这三大领 域，已在跨行业范围内形成了较为广泛的共识。

本白皮书将首先聚焦于“现代企业 — 业务平台化” 的趋势。我们再提“业务平台化”，源于我们在不同 的行业和企业当中，反复观察和接触到、并致力于帮 助解决的一系列新问题，这些问题背后所体现的趋势 和解决的思路与方法，将赋予现代企业新的内涵。 

1.1 “中台”概念的提出、流行到深水区实践， 折射出本轮数字化转型中以“业务平台化”为代 表的企业现代化趋势  

1）以互联网巨头中台化为原点，延伸到以 零售、金融、电信为代表的传统行业数字 化建设，中台实践正在进入到深水区 从 2015 年开始，以阿里巴巴为代表的各互联网巨 头，陆续开启中台化进程（如图 1）。随后，“中台” 理念和相关实践开始快速向各行业渗透和发展  。

零售行业

得益于阿里在零售行业的渗透和影响，以及电商在 过去十年的高速发展，零售行业最先试水“中台”。一方面，阿里本身将中台理念与实践结合云服务向 各行业输出，同时零售行业因业务模式的相似性， 也具备较好的适配基础。另一方面，围绕电商业务 模式，一系列厂商将其中标准化程度较高的部分快 速“中心化”，如“商品中心”，“订单中心”，“支 付中心”等，以“中台”的形态进行实施，也在一 定程度上促进了中台在零售行业的推广。而零售行 业的中台模型，因其本质是对于交易合同及履约的 业务抽象，具备较广的适用性，也常被其他行业借 鉴和扩展 。

金融行业

对于金融行业，打造中台能力，无论在银行、证券 或是保险等细分行业，均已是高度共识的战略举措 之一。（参考文献 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 系统各组成部分的自治性，使得变更能够相对独立的，在更小的边界范围内，以小步快跑 的方式发生，同时还需要保持一定的一致性，使整体架构做到“形散神聚”。

因为无论是创新也好，集中管控也好，虽然变化速 率不同，但变化始终存在，既然变化不可避免，我们应将精力投入到应对变化上。而一个清晰的应用边界划分，可以对于业务能力通过对于知识边界的解耦，实现知识的黑盒复用，对于变化的响应非常有帮助。

在我们的经验中，应用边界划分不合理会对应对变化产生明显的负面作用。一般来说，边界的粒度过粗，容易产生功能、运行层面的变更冲突，而边界的粒度过细，则带来了额外的变更成本和性能开销， 这里对各种负面作用暂不作展开，但它们的共同点是都会拖慢 IT 支撑的响应力或稳定性。

因此，“如何划分 IT 系统的应用边界，以合理的布 局更好地应对变化”是需要解决的问题。进一步拆 解，我们认为需要回答：

• 如何划分应用构建块的逻辑边界，使其尽可能 职责单一、接口规范明确，容易变更和组装？

• 如何组合应用构建块成为合适粒度的独立可 部署单元，尽可能减少功能、运行层面的变更冲突？ 

• 如何描述、留存以上决策的结果和依据，当变 化发生时，通过溯源做出优质的新应对？

3) 如何适当拆分过于集中的分析类数据处 理职责，以缓解规模化数据分析处理瓶颈？

长久以来，业界对数据架构的通用做法是：对于运行类（Operational）和分析类（Analytical）场景， 应该使用不同的设计方法和技术支撑。

运行类场景以业务事务为主线，关注点在于业务事务运作证据的完整性和一致性，以及确保各类数据在各业务单元间高效、准确地传递，实现跨业务单 元的事务推进以及对于业务溯源的支撑。分析类场景则需要对内、外部数据进行收集和加工， 用来度量业务运行表现、尝试分析产生偏差的原因， 甚至结合机器学习等技术给出对于未来发展趋势预 测和判断，尝试构建数据驱动运营的企业组织。

数据想要形成分析类价值，背后需要经过摄取 （Ingest）- 加工（Process）- 能力包装（Serve） 三大工序，其又可以进一步分为数据仓库、数据湖、 数据与 AI 平台、数据中台等构建模式，它们都有着 各自不同的适用场景和技术栈，针对这些模式的差 异我们暂不作展开。由于分析类场景所要求的方法和技术与运行类场景有着显著的不同，许多企业组建了专职的数据团队， 将分析类数据处理工作和其背后的复杂性打包成为 一个黑盒，提供端到端的统一的数据类企业级服务与支撑。

这个模式对于业务场景简单的企业环境工作得不 错，但对于多业务线、业务平台化的企业环境已初显疲态。一方面，随着 IT 建设加速，数据源和分析 类场景的数量激增，对数据类服务的响应力提出了 更高要求。另一方面，想要提供高质量的数据类服务，除了分析类数据的专业技能，还要求对于业务场景、现有应用软件的深入理解。如果所有工作仍然只由专职的集中式团队一肩挑，团队带宽的限制 必然会拖慢响应力。

因此，我们认为需要探索的是如何适当拆分过于集 中的分析类数据处理职责，为集中式的数据团队减 负，使其可以将精力投入到高价值的分析类场景中。 

4）如何在富技术时代进行平台型技术架构 选型及设计？

受益于云原生架构的兴起与发展，新技术的涌现和 不断成熟，及技术工具的极大丰富，技术架构设计 的灵活度和效率都得到了显著提升。

另一方面，在平台型技术架构的设计中，作为多业务线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，技术架构的设计困难 度正呈现指数级增长。而一直以来，本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显：

• 对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的 研发成本

• 架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响

• 架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，技术架构方案容易进入“完成即落伍” 的困局。 

1.3 企业架构设计方法，是有效的工作方法， 经典的企业架构框架已不足够应对业务平台化中的新问题  

1）以企业架构框架方法进行业务平台设 计，是有效的工作方法，且各主流方法各有侧重  

业内越来越普遍的采用企业架构框架，作为业务平台化整体规划指导和方法，这是有效的。因为各类 企业架构框架的元模型，大体都可以归结为四类视图，即业务架构、应用架构、数据架构和技术架构， 尽管不同框架在具体的层级划分、及各层结构下的内容涵盖可能会略有不同。这样的结构较好的匹配 了业务平台设计的问题域。

同时各类企业架构框架的工作逻辑相似，均是从愿 景与业务目标出发自顶向下的贯穿设计，并保持从业务到技术的一致性，这样的工作逻辑与业务平台 从设计到落地的逻辑一致。在此基础上，不同的企业架构框架，由于产生的背 景和发展过程的不同，形成各自的侧重点或行业属 性，这也从另外一个方面加强了其适用性。例如：Zachman：侧重从利益相关者的六个视角来描述企业

TOGAF：强调企业架构全生命周期治理

DoDAF/FEAF-II：面向政府机构的投资组合管理， 注重ViewPoint

BIAN：面向银行业，有银行业开箱即用参考模型

需要说明的是，以上的侧重总结，仅代表我们在项目操作中的理解，实际上，每一种框架在框架设计上都是完备的，在各自的领域和适用场景中也得到 了广泛的应用。

2）经典的框架更注重概念的完整性，工程 实操性仍显不足，且对业务平台化的新问 题均没有特定的设计和考虑 

下面这张表格，体系化的从概念、建模、流程的角度， 对若干经典企业架构框架进行对比，从中我们可以 清晰的解读出，在 Concept（概念）层面的各项评估中，各框架普遍的评定都在 H（高）和 M（中）， 而从 Moddling（建模）开始，到 Process（流程）， 评定开始从 M（中）转向 L（低），其中和落地的 相关性越高的评估项，普遍的评定都位于 L（低）。 

这张表格出自 2015 年的一篇学术文章（参考文献 6），在这之后的 5 年时间里，各框架也均不同程 度地对实操的内容进行了补充和增强。但从我们的实际的跟进研究和项目经验来看，各经典框架在项 目工程实操性中仍显不足。这可能也与企业级架构 框架的定位相关，其大多数的定位都偏向于战略规划和组织级管理与治理，对于架构在具体设计和建 模层面都没有进行细粒度展开。

同时，在第二小节中所提及的，在业务平台化的背 景和趋势下我们所面临的新问题，也可映射到企业 架构框架元模型的四个层次中：

• 业务架构层：如何抽离多业务线共享的能力， 以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？

• 应用架构层：在宏观规划层面，如何有效的划分和组织能力，如何划分 IT 系统的物理边界， 以合理的布局更好地应对变化，在局部设计层 面，如何在最大化复用效果的同时，保障对差 异化需求的响应力？

• 数据架构层：如何适当拆分过于集中的分析类数据处理职责，缓解规模化瓶颈

• 技术架构层：如何在富技术时代进行平台型技术架构设计 这些在当前时代背景下广泛存在的新课题，从各经 典企业架构框架中也无法直接找到针对性的设计参考和考量依据，需要我们进一步思考、实践与提炼 。

1.4 ThoughtWorks 在经典企业架构框架基础 上，面向以业务平台化为代表的企业现代化转 型中的新问题，发布现代企业架构框架  

本白皮书提出的现代企业架构框架就是在这样的背景下，针对以业务平台化为代表的企业现代化转型 过程中的背景及挑战，从实践中探索和总结出的一 套轻量级、敏捷、可落地的企业架构框架方法。

整体框架方法设计保持对经典企业架构框架优秀设计部分的传承，从框架元模型整体结构上，仍遵循经典企业架构框架的最佳实践，延续基于业务架构、 应用架构、数据架构及技术架构的架构视图分类。而针对业务平台化的特征及新问题，对各层元模型内容，进行了扩展和再定义。

与此同时，这套框架力求实操，对于每一层模型的 讲解，我们都以问题作为牵引，以解决问题的实操 过程作为内容串联主线。因此，每一个部分的详细介绍中，我们按照这样的顺序进行讲解，先给出该 层元模型概览，之后回顾问题，以问题的解决过程 作为牵引，讲解元模型的应用  。

2.现代企业架构框架 （Modern Enterprise Architecture Framework - MEAF）

企业架构（Enterprise Architecture）始于 20 世纪 60 年代，截至目前已有接近六十年的发展历程， 作为一门关键的 IT 学科领域，经过多年的发展也催 生了各类广泛应用于各行业和应用场景的框架与方法论工具，例如 Zachman、TOGAF、DoDAF 等， 这些企业架构框架也一直作为重要的指导方法和工具，被应用于各类企业和组织的顶层 IT 规划与设计。

但随着近些年互联网的高速发展，“互联网速度” 和“产品为王”的理念直入人心，也导致企业将更 多注意力和资源聚焦于产品（系统）架构层面，关 注于如何通过合理的系统架构设计帮助产品快速抢占市场和用户，获得成功。

这样的产品驱动型策略，切实帮助了很多企业快速 通过核心产品的构建和发布，迅速占领市场，获得 了阶段性成功。但同样也是因为缺乏对于企业级架 构的整体规划与设计，当企业逐渐深入到可持续发 展和业务持续拓展阶段，产品重复建设、技术与架 构大规模异构等问题逐渐显现，给企业带来了越来 越大的负担，拖慢了企业持续发展和持续创新的速度。

因此，企业架构重新被大家关注和重视，以互联网 巨头为代表开始了一系列的企业级架构重新规划和 治理的工作，其中“中台战略”就是典型的代表。这样的趋势也正在从互联网行业蔓延到其他行业， 掀起了一波企业级架构规划和治理的新浪潮。

至此，企业架构和企业架构框架又重新回归大家的视野，成为企业架构治理和企业平台化转型，乃至企业数字化转型的重要理论依据和指导工具。 

2.1 企业架构

在展开描述企业架构和企业架构框架之前，首先追根溯源，了解一下架构的含义，在 ISO/IEC/IEEE42010:2011 标准中对于架构的定义是：

架构是系统在其所处环境中的基本概念或属 性，体现为它的元素、关系，以及系统设计和演进的原则。

架构这个概念源于建筑等其他行业，随着计算机行业的兴起，这样的概念也被引入到了信息 技 术 行 业， 用 于 IT 系 统 的 设 计。在信 息 技 术 领域大体上主要分为两个粒度，即：系统架构 （System Architecture）与企业架构（Enterprise Architecture）。

信息技术领域的架构设计本质是一个认知、抽象与 构建的过程，即通过对于物理世界的认知与抽象， 识别其中的关键概念及其关系，再通过数字化的手 段在数字化世界里重新构建、模拟和还原。

而企业架构同样作为一种架构体系，也依然符合对于架构的概念定义，只是将关注点从系统级别提升到了企业级别，即企业架构关注的是在企业级别的各种视角（viewpoint）及其视图（view），其中的 基本元素及其关系。

通过对于企业架构的规划和设计，可以帮助企业构 建整体的数字化策略，规划数字化项目，通过数字 化的手段帮助其实现期望的战略目标和业务结果， 形成企业的数字化顶层规划与设计，指导企业的 数字化转型过程。而这个企业架构规划的过程， 也被称为企业架构规划 (enterprise architecture planning, EAP)

2.2 企业架构框架  

很多人将企业架构（Enterprise Architecture） 与企业架构框架（E n t e r p r i s e A r c h i t e c t u r e Framework）的概念混淆，就像很多人容易将敏捷 （Agile）与轻量级软件开发方法（如Scrum）混淆 一样，其实这是两个完全不同的概念。 

企业架构是一门领域学科，而企业架构框架（例如 常见的 TOGAF）才是一种具体可实施的框架和方法 论，企业架构与企业架构框架的关系，就类似于敏 捷（Agile）与轻量级软件开发方法（例如 Scrum、 XP）的关系一样。在众多的企业架构框架方法之中，最被大家熟知通 用型企业架构框架当属 TOGAF，其已经成为通用行 业企业架构框架的标准方法。而近些年大量新涌现 的轻量级企业架构方法，也大多从TOGAF发展而来， 或是对于 TOGAF 进行扩展，或是对于 TOGAF 进行 细化和补充。   

2.3 现代企业架构框架  

虽然如上所述，像 TOGAF 这样的经典企业架构框架从诞生到今已经历了 20 多年的发展，在发展和演进过程 中也与时俱进地加入了对于像 SOA 等新的架构模式的支持。但在具体应用框架方法实践与解决现在化企业所面临的问题时，例如如何在云与分布式时代，基于 平台思维进行企业架构设计的过程中仍显繁重且不完全匹配。

终究其原因，这类经典企业架构框架所诞生的时代 仍处于信息化时代的早期，设计之初主要面对和解 决的是企业信息化的问题，虽然也在持续保持演进 和发展，但大多以补丁（例如通过元模型扩展的方 式）的方式予以支持，并不能做到与最新的企业发 展理念和技术趋势无缝融合与原生支持，尤其是在 以平台型为主要特征的现代企业架构的规划与设计 过程中，最典型的就是国内目前比较广泛采用的中 台架构规划过程中，略显乏力。 

因此，不破不立，能否在充分吸收经典企业架构框 架的优秀思想和最佳实践的前提下，融合最新的企 业数字化发展的需求和新技术新趋势，勇于跳出 TOGAF 的限制，从问题出发，回归第一性，重新思考和构建一个新的轻量级企业架构框架，切实可以解决企业在向现代企业架构演进过程中面临的问题和挑战，就成为我们重点关注和研究的领域。通过几年的研究实践，也逐渐形成了一套轻量化、敏捷 可落地的企业架构框架方法，我们把它定义为：现代企业架构框架（Modern Enterprise Architecture Framework）。   

2.4 现代企业架构框架设计原则  

当我们在总结和提炼现代企业架构框架（MEAF）时， 为了保证框架设计的有效和易于实施，从框架设计之初就一直遵循以下框架设计原则：

• 战略与业务价值驱动（业务驱动 over 技术 驱动）

战略与业务价值驱动，是框架设计的第一个重要原则，无论是框架本身的设计还是应用框架进行 业级的架构规划，都需要始终遵循此规则，使每 一个架构决策都能回溯到企业的战略方向和业务价值上。

为了达到此目标，无论是企业级的应用架构还是企 业级的技术架构，都需要以支撑企业级的业务架构为目标，而企业级的业务架构要能直接对应和反应 企业的战略方向以及业务价值体现。

一切从业务出发，以价值驱动，是架构设计的重要 原则与基础。

• 轻量敏捷化（持续改进 over 一次做对）

为保证架构的轻量，从框架设计之初，团队一直反 复审视框架每一个概念和工具的价值和成本，在满足现代企业架构设计的前提下，力求用最少的概念 和元素解决实际问题。

同时如何让企业架构与敏捷的思想融合，也是我们在框架设计之初就一直探讨和研究的课题。我们希望同时结合 ThoughtWorks 在敏捷与企业架构及平台架构各个领域的优势和理解，使现代企业架构框 架原生就融入敏捷的思想、原则和最佳实践，扭转 大家对于企业架构“繁重、复杂、成本高、不落地” 的固有认识。

为达到此目标，我们将数据驱动、持续迭代、小步快跑、协同共创、工作坊等思想、方法和工具也融入到了现代企业架构框架之中，帮助在框架实施过 程中实现企业级架构规划与建设的敏捷化 。

• 可落地（从实践出发 over 从理论推导）

本框架在设计过程中的所有元模型定义和方法建议，都源于实际项目的实践和提炼，因为可落地易落地也一直是我们构建和设计这个框架的重要原则之一，任何好的概念、思想和工具，如果没有经过实践的检验，也不会被加入到框架的核心模型和要素中来。

反映到框架设计上，从框架的核心元模型出发，每 一个元模型要素都会包含完整的概念定义、应用场景、建模语言标准、识别方法与工具建议、输入基线要求、输出基线定义，以确保框架的可落地和应用此框架设计与建模的一致性，同时降低框架掌握 的门槛，做到易懂、易学、易用。

同时，对于框架从元模型出发到设计与建模方法， 支持基于企业的自身特点和不同的战略目标以及业务要求，支持对于框架做出适当的裁剪、扩展和定制，使框架切实成为企业级架构规划的有力支撑而非固化限制。

2.5 现代企业架构框架元模型总览  

在展开介绍架构之前，我们需要先了解在企业架构领域非常重要的三个概念：元模型（Metamodel）， 视角（viewpoint）和视图（View）：

元模型（Metamodel）：元模型是对于架构核心 概念要素的精确定义和描述，元模型构成了架构设计的“基本语言要素”，通过元模型及其关系的表 达，就可以通过结构化的方式对于架构进行描述和展现，框架元模型体现了框架设计者对于企业级架 构本身的理解和抽象，是企业级架构框架的核心， 是对于架构描述的“统一语言”。

视角（Viewpoint）：企业架构设计因为是在对于 企业本身的进行架构设计，因其抽象程度较高，同时涉及各类不同的干系人和组织，而不同的干系人 和组织基于自身所处岗位角色和职责的不同，对于架构的关注点和视角也存在比较大的差异。因此， 通过不同的视角（Viewpoint）的抽象，就可以充分体现我们在审视和进行企业架构设计时，处于什么样的观察位置和角度，兼顾不同干系人的架构设计 诉求。不同的视角（Viewpoint）会关注架构的不同切面，以及在这个切面下的元模型要素以及他们之间的关系，这就构成了不同的架构视图（View）。

视图（View）：一个视图描述了从一个或一组相关 的视角（Viewpoint）出发，通过组合这类视角所关注的元模型（Metamodel）要素及其关系，通过设计与建模之后，形成的切面视图。一个视图（View） 体现了在一类视角（Viewpoint）下对其关注的架构 元模型要素及其关系的描述和可视化。在现代企业架构框架（MEAF）的设计上，我们最大化的延续和集成了经典企业架构框架对于视角 （Viewpoint）和视图（View）的划分，当前版本 主要从业务架构、应用架构、数据架构和技术架构出发四类架构视图出发，将关注点聚焦于在不同架构视图下，针对平台型企业架构设计这个大的前提和背景，如何设计和应用元模型（Metamodel）重 新对于企业架构建模，满足企业对于现代企业架构设计的需求的同时，保证企业架构设计的可落地。

参考文献

原文：https://mp.weixin.qq.com/s/FUp6hu30sjXVbfHanhJGkA

参考文献 1 《国际数据公司（IDC）3 月份的 CXO 月度调研》 国际数据公司

参考文献 2 《趋势洞察：数字加速，在危机时期推动增长的主要技术》 IBM 商业价值研究院

参考文献 3 《从技术走向商业看“中台” 投资机会》 中银国际证券

参考文献 4 《中国行业趋势报告 -2020 年度特别报告》 罗兰贝格

参考文献 5 2019 恒生电子技术开放日 

参考文献 6 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