《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系统各组成部分的自治性,使得变更能够相对独立的,在更小的边界范围内,以小步快跑的方式发生,同时还需要保持一定的一致性,使整体架构做到“形散神聚”。因为无论是创新也好,集中管控也好,虽然变化速率不同,但变化始终存在,既然变化不可避免,我们应将精力投入到应对变化上。而一个清晰的应用边界划分,可以对于业务能力通过对于知识边界的解耦,实现知