《ThoughtWorks现代企业架构框架白皮书_V4.docx》由会员分享，可在线阅读，更多相关《ThoughtWorks现代企业架构框架白皮书_V4.docx（72页珍藏版）》请在课桌文档上搜索。
1、ThoughtWorks现代企业架构白皮书数字化转型底层方法论1 .弓I言：再提业务平台化41.1 “中台”概念的提出、流行到深水区实践，折射出本轮数字化转型中以“业务平台化”为代表的企业现代化趋势51.2 再提业务平台化，是因为深水区实践中，新的问题将业务平台化内涵向前演进一-81.3 企业架构设计方法，是有效的工作方法，经典的企业架构框架已不足够应对业务平台化中的新问题111.4 ThoughtWorks在经典企业架构框架基础上，面向以业务平台化为代表的企业现代化转型中的新问题，发布现代企业架构框架132 .现代企业架构框架(ModernEnterpriseArchitectureFram
2、ework-MEAF)142.1 企业架构152.2 企业架构框架-152.3 现代企业架构框架162.4 现代企业架构框架设计原则172.5 现代企业架构框架元模型总览一783 .现代企业架构框架一业务架构203.1 业务架构元模型综述-203.2 业务架构元模型应用223.3 业务架构元模型补充说明-394 .现代企业架构框架一应用架构424.1 应用架构元模型综述-434.2 应用架构元模型应用一435 .现代企业架构框架一数据架构525.1 数据架构元模型综述一535.2 数据架构元模型应用536 .现代企业架构框架一技术架构586.1 技术架构元模型综述596.2 技术架构元模型应用
3、597 .总结688 .参考文献691引m2020年是“黑天鹅”集中爆发的一年，也是数字本轮以数字化驱动业务创重塑，越来越清晰的化新波浪潮涌起的年。数字化转型的声浪正在再提业务平台化以加速的态势进入到各行业、各企业的战略主航道。领域。尽管不同的行业、组织和企业，对上述领域以数字化的方式对于业务进行创新与重塑，正在成的表述和内涵界定可能会存有差异，或仍有其他特为企业新的发力点和主战场。定领域的特征显现，但在我们的观察中，这三大领多项研究调查显示，60%以上的受访高管们（参考文献1、2）,在疫情之后，都充分意识到数字化的必要性和对于企业带来的机遇，并表示正在着手加速企业的数字化步伐。而疫情期间，快
4、速拥抱数字化的组织，所展现的绩效水平在其所在行业的横向对比中，也均显著优于竞争对手（参考文献2）。域，已在跨行业范围内形成了较为广泛的共识。本白皮书将首先聚焦于“现代企业一业务平台化”的趋势。我们再提“业务平台化”，源于我们在不同的行业和企业当中，反复观察和接触到、并致力于帮助解决的一系列新问题，这些问题背后所体现的趋势和解决的思路与方法，将赋予现代企业新的内涵。中台概念的提出、流行到深水区实践，折射出本轮数字化转型中以业务平台化为代表的企业现代化趋势1）以互联网巨头中台化为原点，延伸到以零售、金融、电信为代表的传统行业数字化建设，中台实践正在进入到深水区从2015年开始，以阿里巴巴为代表的各
5、互联网巨头，陆续开启中台化进程（如图1）。随后，“中台”理念和相关实践开始快速向各行业渗透和发展。零售行业得益于阿里在零售行业的渗透和影响，以及电商在过去十年的高速发展，零售行业最先试水“中台”。一方面，阿里本身将中台理念与实践结合云服务向各行业输出，同时零售行业因业务模式的相似性，也具备较好的适配基础。另一方面，围绕电商业务模式，一系列厂商将其中标准化程度较高的部分快速“中心化”，如“商品中心”，“订单中心”，“支付中心”等，以“中台”的形态进行实施，也在一定程度上促进了中台在零售行业的推广。而零售行业的中台模型，因其本质是对于交易合同及履约的业务抽象，具备较广的适用性，也常被其他行业借鉴和
6、扩展。金融行业对于金融行业，打造中台能力，无论在银行、证券或是保险等细分行业，均已是高度共识的战略举措公司崛中台相关事件阿里巴巴2015年12月宣布全面启动“中台战略，构建符合大数据时代的“大中台、小前台”组织机制和业务机制腾讯2018年9月组织架构调整，“扎根消费互联网，拥抱产业互联网”，在技术上开源节流，自研上云，全面建设中台美团2018年11月尝试打通各个业务之间的数据，实现用户端的账户统一，实现用户数据中台京东2018年12月发布组织调整，采用“中台”的组织概念，中台部门已TOB为主，包括3C电子及消费品零售事业群、时尚居家平台事业群、生活服务纵嚅、技术中台秘媾中台、商城用户体验设计部
7、、商城市场部等六个核心部门字节跳动2019年3月搭建“直播大中台”，“直播大中台”将抖音、西瓜视频和火山小视频三个短视频产品抽山、合并，支撑字节跳动旗下的所有直播业务资料来源：腾讯科技、公司公告，中银国际证券（图1.1-1互联网企业的中台化大事件）（参考文献3）之一。（参考文献4、5）当行业越来越重视客户一致性体验，开始打造开放银行，深度运营客户，构建生态的同时，对于长期掣肘金融行业发展的历史遗留问题，企业也深刻意识到对于此类问题解决的迫切性。如庞大的遗留系统难以响应前端快速的业务创新、客户和业务数据孤岛现象严重、组织架构壁垒高筑等。而中台建设被认为是行业普遍认同的求解之道，根据恒生调研，半数
8、金融机构正在考虑建设业务中台，90%金融机构认为未来两至三年会建设业务中台。（参考文献4、5）电信行业以IT基础设施作为重要支柱的电信行业，始终保持对IT新技术与工程实践的关注和引入。过去5年，伴随通信技术的快速换代所带来的新的市场特征，围绕业务响应力提升和研发效能改进的目标，电信行业IT基础设施经历了新一轮的翻新和升级：研发体系的敏捷转型，DeVe）PS体系搭建、大型核心系统的容器化及服务化改造。在此基础上，加之“新基建”顶层设计的牵引和推动，行业整体的IT基础设施进一步深化，中台建设作为突破点和抓手之一，在营销、服务、网运等多层面展开，并不断取得进展。2）ThoughtWorks在以上行业
9、中台建设的深入实践认为，中台不是目的，而是手段，平台化向业务的再演进，是本车合数字化建迦的重要赛争各回顾ThOUghtWorkS对于中台的实践，我们持续向行业输出一系列思考和洞见的同时，也广泛且深入参与了各行业的数字化建设中、尤其是以上三大行业中领跑企业的中台建设过程。在我们的经验中，不同的行业，中台有着不同的最佳适配领域，这里从前面提到的三大行业中，我们列举一些各自领域关注的方向： 零售多品牌集团型企业：关注如何通过中台建设，实现集中管控前提下营销能力在多品牌复用 跨国零售企业：关注如何通过中台建设，实现全球统一运营下的核心业务能力针对中国市场的复用与差异化适配，以适应中国的特有业务场景和业
10、务发展 商业银行与金融机构：关注在特定业务（如信贷、资管）场景的能力抽取与模式复用，实现对于金融产品的快速创新的加速，和金融电商化的渠道能力运营的加强，为生态建设奠定基础 通信企业：关注如何实现跨业务线之间的公共能力的识别，沉淀，形成统一管控及支撑，实现产品平台化，更灵活的适配不同场景的需求与快速响应。这些领域中，中台的差异化适配和建设，印证了中台实践已进入深水区。而与此同时，中台实施“失败”的案例也不绝于耳，行业对“中台”观点，出现清晰的分化。这里，我们不展开对于中台实施失败案例的讨论与分析，而将关注点放在更加底层的商业逻辑和方法论沉淀上来。中台建设不是广义软件套件实施：中台建设“是于企业业
11、务模式端到端的深度分析、建模与复用：在我们看来，中台建设的成功，或者“失败”，甚至“去中台化”声音背后，本质上是一致的商业逻辑:中台以“复用”之名起源，因此，一些案例中，很容易走回从前软件套件实施的思路，以“套件化”的模式，加上一定程度的开放和定制，实现“复制”。“复制”、“复用”一字之差，却意味着从规划到落地截然不同的方法和实现。由此带来的问题是，曾经套件化实施过程中围绕“削足适履”出现过的问题、走过的弯路，在中台规划与建设中，如果仍以“中台产品套件”实施方式，会不可避免的再次出现。中台究竟在复用什么？我们给出的答案是：中台是针对于“商业模式”和“业务模式”的抽象与复用。背后体现的是企业希望
12、通过对于自身商业模式的不断思考与认知，再通过自身业务模式的抽象与沉淀，实现跨地域、跨用户、跨场景、跨领域的扩展与复用，支撑企业业务的快速拓展与创新，也体现和契合了平台向业务的再演进过程。借用我们一位咨询师的话：“看上去的能力复用是乐高组装，但真实的能力更用其实是器官移植，需要的是一场外科手术。”因此，我们认同这样的观点：“中台”是手段、过程，不是目的本身。回归本源，从问题与价值出发，“平台化”向业务的再演进，是这一轮数字化建设浪潮中需要关注的重要趋势，也是企业现代化进程中的关键步骤。1.2再提业务平台化，是因为深水区实践中,新的问题将业务平台化内涵向前演进“平台化”是从信息化到数字化时代，每一
13、轮IT建设都会提及的主题之一。而当平台沿着历史发展的趋势继续向业务的“逼近”过程中，对于平台抽象和建设的难度也成指数型增加，涌现出了一系列新问题。对于这些问题的思考和解决方案的探索，也将赋予业务平台化这个趋势以新的内涵和意义，同时也是我们设计和发布新的企业架构框架的起心动念。这些问题的“新”意、,更多的体现在“how”上，而不再仅仅是“what，所以我们以“如何”的句式来逐一总结和简述：D如何抽离多业务线共享的解决方案和能力，集中管控和演进，以避免重复投资？新业务如何基于企业已有的解决方案和能力快速组装上线，以支撑业务快速迭代创新？今天，业务发展和IT建设的绑定比以往任何时间都更加紧密，而当大
14、型企业的业务涉猎已足够广泛，多条业务线、或者多个业务单元并行发展，IT建设会随着业务边界、组织边界，不可避免的进一步分化，也加剧了IT部门进行统一管控的困难。一方面，在很多场景中，这样的分化带来了双重投资甚至多重投资的浪费：另一方面也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT翻新周期长等固有问题。同时，当业务线不断尝试新的业务模式，或对于已有模式进行更快的试验、调整与扩展。对于IT支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景应对下，成本高昂。因此，如何抽离多业务线共享的解决方案和能力，集中管控和
15、演进，以避免重爱投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？是需要解决问题。进一步拆解，我们认为需要回答： 针对不同的业务深度，如何设计“模式”与“能力”模型，以对业务进行合理的抽象，进而识别相似度，抽象与提炼可复用的业务模式；而针对不同业务的差异性，如何在“模式”和“能力”基础上进行扩展？ 抽象并沉淀了业务能力之后，如何在新的业务场景中，识别、复用已有能力，应用、数据、技术及组织应该如何予以支撑？ 以上的工作过程，是否有较好的工作实践和参考模型？2)如何合理地划分IT系统边界，以得到随需而变的响应力除了能力复用外，另一个提升IT支撑响应力的关键是，提升IT系统各组成部分
16、的自治性，使得变更能够相对独立的，在更小的边界范围内，以小步快跑的方式发生，同时还需要保持一定的一致性，使整体架构做到“形散神聚”。因为无论是创新也好，集中管控也好，虽然变化速率不同，但变化始终存在，既然变化不可避免，我们应将精力投入到应对变化上。而一个清晰的应用边界划分，可以对于业务能力通过对于知识边界的解耦，实现知识的黑盒更用，对于变化的响应非常有帮助。在我们的经验中，应用边界划分不合理会对应对变化产生明显的负面作用。一般来说，边界的粒度过粗，容易产生功能、运行层面的变更冲突，而边界的粒度过细，则带来了额外的变更成本和性能开销，这里对各种负面作用暂不作展开，但它们的共同点是都会拖慢IT支撑
17、的响应力或稳定性。因此，“如何划分IT系统的应用边界，以合理的布局更好地应对变化”是需要解决的问题。进一步拆解，我们认为需要回答： 如何划分应用构建块的逻辑边界，使其尽可能职责单一、接口规范明确，容易变更和组装？ 如何组合应用构建块成为合适粒度的独立可部署单元，尽可能减少功能、运行层面的变更冲突？ 如何描述、留存以上决策的结果和依据，当变化发生时，通过溯源做出优质的新应对？3)如何适当拆分过于集中的分析类数据处理职责，以缓解规模化数据分析处理喻？长久以来，业界对数据架构的通用做法是：对于运行类(OPeratiOnal)和分析类(Analytical)场景，应该使用不同的设计方法和技术支撑。运行
18、类场景以业务事务为主线，关注点在于业务事务运作证据的完整性和一致性，以及确保各类数据在各业务单元间高效、准确地传递，实现跨业务单元的事务推进以及对于业务溯源的支撑。分析类场景则需要对内、外部数据进行收集和加工，用来度量业务运行表现、尝试分析产生偏差的原因，甚至结合机器学习等技术给出对于未来发展趋势预测和判断，尝试构建数据驱动运营的企业组织。数据想要形成分析类价值，背后需要经过摄取(Ingest)加工(Process)-能力包装(Serve)三大工序，其又可以进一步分为数据仓库、数据湖、数据与Al平台、数据中台等构建模式，它们都有着各自不同的适用场景和技术栈，针对这些模式的差异我们暂不作展开。由
19、于分析类场景所要求的方法和技术与运行类场景有着显著的不同，许多企业组建了专职的数据团队，将分析类数据处理工作和其背后的复杂性打包成为一个黑盒，提供端到端的统的数据类企业级服务与支撑。这个模式对于业务场景简单的企业环境工作得不错，但对于多业务线、业务平台化的企业环境已初显疲态。一方面，随着IT建设加速，数据源和分析类场景的数量激增，对数据类服务的响应力提出了更高要求。另一方面，想要提供高质量的数据类服务，除了分析类数据的专业技能，还要求对于业务场景、现有应用软件的深入理解。如果所有工作仍然只由专职的集中式团队一启挑，团队带宽的限制必然会拖慢响应力。因此，我们认为需要探索的是如何适当拆分过于集中的
20、分析类数据处理职责，为集中式的数据团队减负，使其可以将精力投入到高价值的分析类场景中。4）如何在富技术时代进行平台型技术架构选型及设计？受益于云原生架构的兴起与发展，新技术的涌现利不断成熟，及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。另一方面，在平台型技术架构的设计中，作为多业务线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，技术架构的设计困难度正呈现指数级增长。而一直以来，本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显：对于架构需求把握不足或者没有架构需
21、求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，技术架构方案容易进入“完成即落伍”的困局。因此，我们认为架构师们比以往，更需要这样一个体系：网品系统性的分析结构化的设计沉淀可复用的架构需求架构方案架构经验1.3企业架构设计方法，是有效的工作方法，经典的企业架构框架已不足够应对业务平台化中的新问题1）以企业架构框架方法进行业务平台设计，是有效的
22、工作方法，目各主流方法各有侧重业内越来越普遍的采用企业架构框架，作为业务平台化整体规划指导和方法，这是有效的。因为各类企业架构框架的元模型，大体都可以归结为四类视图，即业务架构、应用架构、数据架构和技术架构，尽管不同框架在具体的层级划分、及各层结构下的内容涵盖可能会略有不同。这样的结构较好的匹配了业务平台设计的问题域。同时各类企业架构框架的工作逻辑相似，均是从愿景与业务目标出发自顶向下的贯穿设计，并保持从业务到技术的一致性，这样的工作逻辑与业务平台从设计到落地的逻辑一致。在此基础上，不同的企业架构框架，由于产生的背景和发展过程的不同，形成各自的侧重点或行业属性，这也从另外一个方面加强了其适用性
23、。例如：Zachman:侧重从利益相关者的六个视角来描述企业TOGAF：强调企业架构全生命周期治理DoDAF/FEAF-ll：面向政府机构的投资组合管理,注重ViewPointBIAN:面向银行业，有银行业开箱即用参考模型需要说明的是，以上的侧重总结，仅代表我们在项目操作中的理解，实际上，每一种框架在框架设计上都是完备的，在各自的领域和适用场景中也得到了广泛的应用。2）经典的框架更注重概念的完整性，工程实操性仍显不足，且对业务平台化的新问题均没有特定的设计和考虑下面这张表格，体系化的从概念、建模、流程的角度，对若干经典企业架构框架进行对比，从中我们可以清晰的解读出，在Concept（概念）层面
24、的各项评估中，各框架普遍的评定都在H（高）和M（中），而从ModdIing（建模）开始,到PrOCeSS（流程），评定开始从M（中）转向1.（低），其中和落地的相关性越高的评估项，普遍的评定都位于1.（低）。TAB1.E1SUMMARYQFCOMPARiSOMAspectsEAPTOGAFDODAFGartnerFEAConceptsAlignment1.MMM1.ArtifackiMHMMMGovernanceMHMM1.ReposiluQMMMMMStrategyHHHMHModelingEasytouseM1.MMMEasytolean)M1.MMMTraceabilityMH1.1.M
25、Consistenc)MH1.1.MDifferentViewsMMM1.MComplexity1.1.1.1.1.Dynamic1.1.1.1.1.PJCV!*Requirement1.H1.1.1.StepbyStepMMMMMDetailedDesignMMMMMInipIemeiHalionMMMMMGuidelinesMHM1.HMaintenance1.M1.1.MContinualMH1.1.1.Notation:H:highconsiderationordetailedandcleardescription:M:mediumConsiderationorlittledescri
26、ption:1.:lowconsiderationorhighleveldescription（图1.3-2企业架构框架对比）（参考文献6）这张表格出自2015年的一篇学术文章（参考文献6）,在这之后的5年时间里，各框架也均不同程度地对实操的内容进行了补充和增强。但从我们的实际的跟进研究和项目经验来看，各经典框架在项目工程实操性中仍显不足。这可能也与企业级架构框架的定位相关，其大多数的定位都偏向于战略规划和组织级管理与治理，对于架构在具体设计和建模层面都没有进行细粒度展开。同时，在第二小节中所提及的，在业务平台化的背景和趋势下我们所面临的新问题，也可映射到企业架构框架元模型的四个层次中： 业务
27、架构层：如何抽离多业务线共享的能力，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？ 应用架构层：在宏观规划层面，如何有效的划分和组织能力，如何划分IT系统的物理边界，以合理的布局更好地应对变化，在局部设计层面，如何在最大化复用效果的同时，保障对差异化需求的响应力？ 数据架构层：如何适当拆分过于集中的分析类数据处理职责，缓解规模化瓶颈 技术架构层：如何在富技术时代进行平台型技术架构设计这些在当前时代背景下广泛存在的新课题，从各经典企业架构框架中也无法直接找到针对性的设计参考和考量依据，需要我们进一步思考、实践与提炼。1.4ThoughtWorks在经典企业架构框架基
28、础,面向以业务平台化为代表的企业现代化转型中的新问题，发布现代企业架构框架本白皮书提出的现代企业架构框架就是在这样的背景下，针对以业务平台化为代表的企业现代化转型过程中的背景及挑战，从实践中探索和总结出的一套轻量级、敏捷、可落地的企业架构框架方法。整体框架方法设计保持对经典企业架构框架优秀设计部分的传承，从框架元模型整体结构上，仍遵循经典企业架构框架的最佳实践，延续基于业务架构、应用架构、数据架构及技术架构的架构视图分类。而针对业务平台化的特征及新问题，对各层元模型内容，进行了扩展和再定义。与此同时，这套框架力求实操，对于每一层模型的讲解，我们都以问题作为牵引，以解决问题的实操过程作为内容串联
29、主线。因此，每一个部分的详细介绍中，我们按照这样的顺序进行讲解，先给出该层元模型概览，之后回顾问题，以问题的解决过程作为牵引，讲解元模型的应用。现代企业架构框架xK、(ModernEnterpriseArchitecturexFramework-MEAF)企业架构(EnterPriSeArchitecture)始于20世纪60年代，截至目前已有接近六十年的发展历程，作为一门关键的IT学科领域，经过多年的发展也催生了各类广泛应用于各行业和应用场景的框架与方法论工具，例如Zachman.TOGAF、DoDAF等，这些企业架构框架也一直作为重要的指导方法和工具，被应用于各类企业和组织的顶层IT规划与
30、设计。但随着近些年互联网的高速发展，“互联网速度”和“产品为王”的理念直入人心，也导致企业将更多注意力和资源聚焦于产品(系统)架构层面，关注于如何通过合理的系统架构设计帮助产品快速抢占市场和用户，获得成功。这样的产品驱动型策略，切实帮助了很多企业快速通过核心产品的构建和发布，迅速占领市场，获得了阶段性成功。但同样也是因为缺乏对于企业级架构的整体规划与设计，当企业逐渐深入到可持续发展和业务持续拓展阶段，产品重复建设、技术与架构大规模异构等问题逐渐显现，给企业带来了越来越大的负担，拖慢了企业持续发展和持续创新的速度。因此，企业架构重新被大家关注和重视，以互联网巨头为代表开始了一系列的企业级架构重新
31、规划和治理的工作，其中“中台战略”就是典型的代表。这样的趋势也正在从互联网行业蔓延到其他行业，掀起了一波企业级架构规划和治理的新浪潮。至此，企业架构和企业架构框架又重新Pl归大家的视野，成为企业架构治理和企业平台化转型，乃至企业数字化转型的重要理论依据和指导工具。2.1 企业架构在展开描述企业架构和企业架构框架之前，首先追根溯源，了解一下架构的含义，在ISO/IEC/IEEE-42010:2011标准中对于架构的定义是：架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则。架构这个概念源于建筑等其他行业，随着计算机行业的兴起，这样的概念也被引入到了信息技术行
32、业，用于IT系统的设计。在信息技术领域大体上主要分为两个粒度，BP：系统架构(SystemArchitecture)与企业架构(EnterPriSeArchitecture)。信息技术领域的架构设计本质是一个认知、抽象与构建的过程，即通过对于物理世界的认知与抽象，识别其中的关键概念及其关系，再通过数字化的手段在数字化世界里重新构建、模拟和还原。而企业架构同样作为一种架构体系，也依然符合对于架构的概念定义，只是将关注点从系统级别提升到了企业级别，即企业架构关注的是在企业级别的各种视角(VieWPOint)及其视图(VieW),其中的基本元素及其关系。通过对于企业架构的规划和设计，可以帮助企业构建
33、整体的数字化策略，规划数字化项目，通过数字化的手段帮助其实现期望的战略目标和业务结果，形成企业的数字化顶层规划与设计，指导企业的数字化转型过程。而这个企业架构规划的过程，也被称为企业架构规划(enterprisearchitectureplanning,EAP)o2.2 企业架构框架很多人将企业架构(EnterPriSeArchitecture)与企业架构框架(EnterpriseArchitectureFramework)的概念混淆，就像很多人容易将敏捷(Agile)与轻量级软件开发方法(如SCrUm)混淆一样，其实这是两个完全不同的概念。企业架构是一门领域学科，而企业架构框架（例如常见的T
34、OGAF）才是一种具体可实施的框架和方法论，企业架构与企业架构框架的关系，就类似于敏捷（AgiIe）与轻量级软件开发方法（例如Scrum.XP）的关系一样。在众多的企业架构框架方法之中，最被大家熟知通用型企业架构框架当属ToGAF,其已经成为通用行业企业架构框架的标准方法。而近些年大量新涌现的轻量级企业架构方法，也大多从Te）GAF发展而来，或是对于ToGAF进行扩展，或是对于ToGAF进行细化和补充。Type*v*MwGvIAWMF*a*o*Z（图2.2-1企业架构框架列表）（参考文献10）2.3 现代企业架构框架虽然如上所述，像TOGAF这样的经典企业架构框架从诞生到今已经历了20多年的发
35、展，在发展和演进过程中也与时俱进地加入了对于像SOA等新的架构模式的支持。但在具体应用框架方法实践与解决现在化企业所面临的问题时，例如如何在云与分布式时代，基于平台思维进行企业架构设计的过程中仍显繁重且不完全匹配。终究其原因，这类经典企业架构框架所诞生的时代仍处于信息化时代的早期，设计之初主要面对和解决的是企业信息化的问题，虽然也在持续保持演进和发展，但大多以补丁（例如通过元模型扩展的方式）的方式予以支持，并不能做到与最新的企业发展理念和技术趋势无缝融合与原生支持，尤其是在以平台型为主要特征的现代企业架构的规划与设计过程中，最典型的就是国内目前比较广泛采用的中台架构规划过程中，略显乏力。因此，
36、不破不立，能否在充分吸收经典企业架构框架的优秀思想和最佳实践的前提下，融合最新的企业数字化发展的需求和新技术新趋势，勇于跳出TOGAF的限制，从问题出发，回归第一性，重新思考和构建一个新的轻量级企业架构框架，切实可以解决企业在向现代企业架构演进过程中面临的问题和挑战，就成为我们重点关注和研究的领域。通过几年的研究实践，也逐渐形成了一套轻量化、敏捷可落地的企业架构框架方法，我们把它定义为：现代企业架构框架（ModernEnterpriseArchitectureFramework）。2.4 现代企业架构框架设计原则当我们在总结和提炼现代企业架构框架（MEAF）时,为了保证框架设计的有效和易于实施
37、，从框架设计之初就一直遵循以下框架设计原则： 战略与业务价值驱动（业务驱动over技术马Wb战略与业务价值驱动，是框架设计的第一个重要原则，无论是框架本身的设计还是应用框架进行企业级的架构规划，都需要始终遵循此规则，使每一个架构决策都能回溯到企业的战略方向和业务价值上。为了达到此目标，无论是企业级的应用架构还是企业级的技术架构，都需要以支撑企业级的业务架构为目标，而企业级的业务架构要能直接对应和反应企业的战略方向以及业务价值体现。一切从业务出发，以价值驱动，是架构设计的重要原则与基础。 轻量敏捷化（持续改进over一次做对）为保证架构的轻量，从框架设计之初，团队一直反复审视框架每一个概念和工具
38、的价值和成本，在满足现代企业架构设计的前提下，力求用最少的概念和元素解决实际问题。同时如何让企业架构与敏捷的思想融合，也是我们在框架设计之初就一直探讨和研究的课题。我们希望同时结合ThOUghtWOrkS在敏捷与企业架构及平台架构各个领域的优势和理解，使现代企业架构框架原生就融入敏捷的思想、原则和最佳实践，扭转大家对于企业架构“繁重、复杂、成本高、不落地”的固有认识。为达到此目标，我们将数据驱动、持续迭代、小步快跑、协同共创、工作坊等思想、方法和工具也融入到了现代企业架构框架之中，帮助在框架实施过程中实现企业级架构规划与建设的敏捷化。 可落地(从实践出发over从理论推导)本框架在设计过程中的
39、所有元模型定义和方法建议，都源于实际项目的实践和提炼，因为可落地易落地也一直是我们构建和设计这个框架的重要原则之一，任何好的概念、思想和工具，如果没有经过实践的检验，也不会被加入到框架的核心模型和要素中来。反映到框架设计上，从框架的核心元模型出发，每一个元模型要素都会包含完整的概念定义、应用场景、建模语言标准、识别方法与工具建议、输入基线要求、输出基线定义，以确保框架的可落地和应用此框架设计与建模的一致性，同时降低框架掌握的门槛，做到易懂、易学、易用。同时，对于框架从元模型出发到设计与建模方法，支持基于企业的自身特点和不同的战略目标以及业务要求，支持对于框架做出适当的裁剪、扩展和定制，使框架切
40、实成为企业级架构规划的有力支撑而非固化限制。2.5现代企业架构框架元模型总览在展开介绍架构之前，我们需要先了解在企业架构领域非常重要的三个概念：元模型(MetamOdeI),视角(viewpoint)和视图(View)：元模型(MetamOdeI)：元模型是对于架构核心概念要素的精确定义和描述，元模型构成了架构设计的“基本语言要素”，通过元模型及其关系的表达，就可以通过结构化的方式对于架构进行描述和展现，框架元模型体现了框架设计者对于企业级架构本身的理解和抽象，是企业级架构框架的核心，是对于架构描述的“统一语言”。视角(Viewpoint)：企业架构设计因为是在对于企业本身的进行架构设计，因其
41、抽象程度较高，同遁应用架构数据架构架构决策愿戏原则规范约束级织(图2.5-2MEAFMetamodel)时涉及各类不同的干系人和组织，而不同的干系人和组织基于自身所处岗位角色和职责的不同，对于架构的关注点和视角也存在比较大的差异。因此，通过不同的视角(Viewpoint)的抽象，就可以充分体现我们在审视和进行企业架构设计时，处于什么样的观察位置和角度，兼顾不同干系人的架构设计诉求。不同的视角(VieWPOint)会关注架构的不同切面，以及在这个切面下的元模型要素以及他们之间的关系，这就构成了不同的架构视图(View)。视图(View)：个视图描述了从一个或一组相关的视角(VieWPoirIt)
42、出发，通过组合这类视角所关注的元模型(MetamOdel)要素及其关系，通过设计与建模之后，形成的切面视图。一个视图(VieW)体现了在一类视角(Viewpoint)下对其关注的架构元模型要素及其关系的描述和可视化。在现代企业架构框架(MEAF)的设计上，我们最大化的延续和集成了经典企业架构框架对于视角(Viewpoint)和视图(View)的划分，当前版本主要从业务架构、应用架构、数据架构和技术架构出发四类架构视图出发，将关注点聚焦于在不同架构视图下，针对平台型企业架构设计这个大的前提和背景，如何设计和应用元模型(Metamc)del)重新对于企业架构建模，满足企业对于现代企业架构设计的需求
43、的同时，保证企业架构设计的可落地。下面就将根据不同的视图(VieW)以元模型(MetamodeI)为主线，展开详细介绍现代企业架构框架(MEAF)的架构设计要素和应用场景。现代企业架构框架构3J业务架构元模型综述业务架构(BUSineSSArchitecture)定义了企业各类业务的运作模式及业务之间的关系结构。它以承接企业战略为出发点，以支撑实现企业战略为目标，通过对于业务能力的识别与构建，并将业务能力以业务服务的方式透出，实现对于业务流程的支撑，并最终通过组织给予保障。业务架构是企业架构的核心内容，直接决定了企业战略的实现能力，是其他架构领域工作的前提条件和架构设计的主要依据。业务架构整体
44、上包括“业务”、“流程”、“组织”、“服务”、“领域”和“模式”六大部分，如下图3.1-1所示：Pattern（模一式一-l1服务1.J11业务服务（图3.1-1企业级业务架构元模型）其中“模式”部分是我们为“平台型”企业架构设计的核心解决方案，包括:Partl流程建模Part2领域建模Part3业务身份建模基础能力建模扩展点与扩展实现建模能力组件建模解决方案建模3.2业务架构元模型应用3.2.1 现代业务架构典型问题在帮助企业构建业务架构的过程中，我们发现大部分企业正面临共同的问题：如何抽离多业务线共享的能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速
45、迭代创新？问题的背景和起因在于，当大型企业的业务发展到达一定规模，多条业务线并存、或多个业务单元并行发展，IT建设会随着业务边界、组织边界，不可避免的进一步分化，也加剧了IT部门进行统一管控的困难。一方面，在很多场景中，这样的分化带来了双重投资甚至多重投资的浪费，另一方面也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT翻新周期长等固有问题。同时，当业务线不断尝试新的业务模式，或对于已有模式进行更快的试验、调整与扩展。对于IT支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景应对下，成本高昂。为了解决上述问题，我们对问题进行了进一步拆解：- Q1：什么是可共享复用的能力？- Q2：如何识别和构建能力？- Q3：如何使用能力，实现新业务快速上线？在对问题进行上述拆解后，我们将基于业务架构元模型逐一解决。3.2.2 什么是可共享复用的能力？在现代企业架构中，面向能力的规划超越面向功能与服务的规划成为企业级业务架构规划的关注要点，如何基于能力的识别与规划，最大化的沉淀企业级可复用的
