数字化转型底层方法论读现代企业架构白皮书

　　这篇文章为我读最近ThoughtWorks发布的《现代企业架构白皮书-数字化转型底层方法论》的关键笔记整理，但是在这个过程中我不会太多的引用或复制书里面内容，而是对书里面的一些内容进行个人观点说明。
　　该白皮书当前在ThoughtWorks官方网站即可以下载，感兴趣的可以自行前往下载。数字化转型架构思想
　　当谈数字化转型底层方法论的时候，首先还是得重新回顾下数字化转型过程中，特别是IT应用建设过程中的核心架构思想究竟是什么？
　　中台是否一无是处？
　　从去年下半年开始，我们就发现要给问题，即从最早中台提出到拆中台，中台这个词被说烂了。但是实际上对大部分人来说，从中台大热到大冷整个演进过程中，仍然没有准确得抓住中台的本质究竟在哪里。
　　正如现在我一提SOA的时候，很多人就反驳我，说SOA是过时的东西，现在都微服务了还在提SOA，对于这类人同样的问题就是看问题不看本质，不去实践，仅仅停留在被他人引导，盲目的追溯热点上。
　　首先我们引用书里面提到的一小段，如下：
　　ThoughtWorks 在以上行业中台建设的深入实践认为，＂中台＂不是目的，而是手段，＂平台化＂向业务的再演进，是本轮数字化建设中的重要趋势。
　　简单来说，中台仅仅是一种思想，而不是一个产品或平台。
　　中台体现的核心思想就是业务平台化，对于共性的业务能力希望进行集中建设，然后再将共性业务能力以可复用的服务方式提供给前台，方便前台快速的构建应用。
　　如果业务能力已经在遗留业务系统中存在，仅仅是将遗留系统可复用能力识别出来，再暴露给前台使用和组装，那么就回到了传统的SOA架构思想。
　　如果企业原来没有遗留系统，新IT建设的时候就做到共性业务能力集中化建设再提供服务，那么这已经属于云计算的思想，云的思想即是一开始就是集中化的，而不是等到到后期去做集成和适配。
　　所以中台这种思想也不是什么新思想。
　　中台架构思想本质还是云和SOA思想的进一步融合。其核心体现的是业务能力组件化和平台化，组件能力共享化和服务化。
　　你只要准确掌握这个思想，基本就知道了中台核心能力，业务能力平台化，平台能力服务化，构建平台+应用的IT应用架构体系，这个企业数字化转型过程中，这种平台化思想，微服务化思想已经相当流行。
　　是否一定构建中台？
　　在讲现代企业架构方法论的时候，我还是想再谈下企业数字化转型过程中是否一定构建中台，如果要简单总结一句就是：
　　在整个IT架构转型过程中，中台这件事不是外界流行或技术趋势必须强加给你的，而是企业自身IT系统建设逐步演进的，这个演进过程中伴随着一个关键，就是企业本身IT治理和业务管控治理能力都在不断的成熟和加强，在这个过程中中台化顺理成章。
　　什么意思呢？
　　中台建设更加IT治理成熟度关系密切，因此中台是逐步演进出来的，而不是全新构建出来的，哪些希望一开始就以平台化，中台化来构建内部IT应用的企业大部分都失败。
　　我们来举例说明下。
　　比如倚天屠龙记里面的乾坤大挪移这个武功秘籍，张无忌为何能够快速地练到8层，9层，而其他人一练反而是走火入魔。这实际是需要的前期九阳神功强大的内功基础打底，否则给你再好的武功秘籍，你没有前期基础反而是走火入魔。
　　再比如天龙部门里面的段誉，刚开始学会六脉神剑的时候完全自己把控不住，有时候灵有时候不灵，不能为己所用。但是段誉还会化功大法，不断吸收别人的内功，不断精进，最后才能够做到游刃有余。
　　我们来重新对比下传统数烟囱式建设和平台化建设模式下的差异，如下：
　　从这个图可以看到，虽然新的平台+应用构建模式下，上层应用的构建速度加快了，可以最大化地复用技术平台和业务平台已有的能力，并快速的组装构建新应用。
　　但是也带来了一个新问题。
　　即前端一个应用要真正运行起来，受到的外围关联和约束越来越多，底层技术和业务平台，只要有任何一个组件运行出现故障，那么都将导致应用无法正常运行。比如上图中的A1这个应用，必须要技术平台3个组件，业务平台2个组件加A1，这6个组件或微服务都高可靠，那么A1才能够高可靠运行。
　　也就是说A1的高可用性变得不受A1的开发团队或开发商自己掌控。
　　所以A1能否高效构建，高可用的运行，就涉及到技术平台+业务中台本身构建的能力成熟度，这个成熟度包括了平台稳定性，服务可复用，可高效运维监控各个方面的内容。也就是说这个实际就是企业转型平台或微服务化的内功。
　　在远行科技参与的一些项目里面，比较明显的一个情况就是甲方本身的IT治理和管控能力成熟度不够，盲目的全新建设和规划中台，微服务，平台+应用，反而导致了后期整体架构难以管控和运维的局面。
　　这个内功足够强大才能够支撑上层应用构建，但是这个内功不是一蹴而就的，而是需要企业自身在IT规划建设过程中不断的去积累和演进。
　　因此当下先进的技术，架构方法本身也需要和企业自身能力适配，如果自身IT治理能力成熟度不够，企业不要去盲目规划建设中台或实施微服务。一个企业IT建设，并不是说越先进的东西就一定适合你，而是要在适当的时间选择最适合的东西。
　　中台究竟在复用什么？
　　在这类引用下白皮书里面关于中台思想和中台复用的一些看法。
　　中台以＂复用＂之名起源，因此，一些案例中，很容易走回从前软件套件实施的思路，以＂套件化＂的模式，加上一定程度的开放和定制，实现＂复制＂。＂复制＂、＂复用＂一字之差，却意味着从规划到落地截然不同的方法和实现。由此带来的问题是，曾经套件化实施过程中围绕＂削足适履＂出现过的问题、走过的弯路，在中台规划与建设中，如果仍以＂中台产品套件＂实施方式，会不可避免的再次出现。
　　中台究竟在复用什么？
　　ThoughtWorks给出的答案是：中台是针对于＂商业模式＂和＂业务模式＂的抽象与复用。背后体现的是企业希望通过对于自身商业模式的不断思考与认知，再通过自身业务模式的抽象与沉淀，实现跨地域、跨用户、跨场景、跨领域的扩展与复用，支撑企业业务的快速拓展与创新，也体现和契合了平台向业务的再演进过程。传统企业架构思想
　　企业架构（Enterprise Architecture）始于 20 世纪60 年代，截至目前已有接近六十年的发展历程，作为一门关键的 IT 学科领域，经过多年的发展也催生了各类广泛应用于各行业和应用场景的框架与方法论工具，例如 Zachman、 TOGAF、 DoDAF 等，这些企业架构框架也一直作为重要的指导方法和工具，被应用于各类企业和组织的顶层 IT 规划与设计。
　　在展开描述企业架构和企业架构框架之前，首先追根溯源，了解一下架构的含义，在 ISO/IEC/IEEE-42010:2011 标准中对于架构的定义是：
　　架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则。
　　那么如何来看待企业架构？
　　又回到我经常谈到的对事物的分析和观察实际始终都是两个视角，一个是静态视角，一个是动态视角。对于企业架构同样的道理，存在静态的结构框架视角，也存在动态的方法论视角。 同时通过动态的方法论将静态结构完整地串联在一起，实现静态和动态的融合。
　　对于企业架构我前面写过多篇文章。
　　更多的还是基于TOGAF企业架构方法论，详细地描述了在业务驱动IT核心指导思想下，如何通过端到端的流程分析，分解，逐步梳理业务架构，数据架构，应用架构和技术架构的过程。完成了核心四个架构内容的输出后，再根据企业业务目标和战略来详细制定可落地的实施演进路线规划。
　　对于任何要给企业，业务和IT不能是分离的，而应该是一种融合的关系。
　　在企业生产运作中，围绕企业核心竞争力和业务价值链，不论是哪种企业架构方法，都脱离不了业务流程，业务组织，人员，业务事件或操作，规则，数据，应用，技术等核心的元素。这些元素共同完成了对一个企业架构的完整描述。
　　传统企业架构的问题？
　　对于传统企业架构，当前说得比较多的问题就是大而全，整个规划周期很长，建设和实施周期也很长，这就导致规划出来的东西可能还没有来得及实施，整个企业本身的战略，业务目标和模式等都一句发生了巨大的变化。
　　即偏重的架构框架和方法论很难满足业务敏捷性的需求。
　　其次，个人认为传统企业架构最大的问题点还是在于其业务驱动的分层解耦思想，或者说是SOA架构思想应用不足。
　　传统的架构方法都是基于业务流程调研，梳理业务架构，数据架构，然后规划应用架构和应用系统功能架构，逐步落地。这里很难看到业务目标和业务能力的解耦。
　　简单来说在数字化转型过程中，当我们提出一个新的业务目标，或一种新的业务运作模式的时候，我们更加希望是通过对业务模式的快速梳理和分解，来搞清楚究竟需要提供哪些业务能力来支撑这个业务模式。
　　其次才是这些业务能力如何来构建。
　　业务能力的构建本身就是我需要构建要给业务组件，其次是这个业务组件需要暴露哪些粗粒度的API接口服务来提供这个能力 。当我们把这个问题想清楚后才会进入到具体的业务组件，业务接口，数据模型的设计阶段。现代企业架构框架MEAF
　　在白皮书里面，ThoughtWorks给出了一个现代企业架构框架MEAF。对于这个框架的设计原则，里面谈到的三点，如下：1.战略与业务价值驱动（业务驱动 over 技术驱动）
　　2.轻量敏捷化（持续改进 over 一次做对）
　　3.可落地（从实践出发 over 从理论推导）
　　简单来说就是业务驱动，敏捷迭代并能够快速落地实施。
　　这个实际和我在前面谈企业数字化转型方法论里面经常谈到的要基于垂直化业务场景快速的进行敏捷迭代实施，是一个道理。
　　对于MEAF核心元模型如下：
　　对于里面的一些关键点我用红色虚线框做了标记。简单总结如下：
　　左边纵向绿色流程步骤，核心仍然是业务流程和业务场景，基于业务流程和场景的梳理来分析关键的业务阶段，业务活动和业务操作。但是这个不是全面分析，而是基于垂直业务场景驱动的分析。
　　其次就是业务架构，业务架构核心变化为了业务组件+业务服务，同时基于业务组件和业务服务梳理进一步构建领域对象。
　　应用架构本身和业务架构匹配，即业务服务转变为应用服务，业务组件转变为应用组件或微服务，同时领域对象进一步抽象进行数据建模，转变为数据组件和详细的数据库设计。在应用详细功能设计过程中，会看到哪些共性基础能力需要使用技术架构层提供的技术组件和技术服务来完成，技术架构从传统企业架构的IaaS层上升到PaaS服务层。
　　业务架构重点1-识别和构建能力
　　注意，在业务架构规划和设计过程中，核心的一个点就是基于业务流程和业务场景梳理和分析，来识别和构建业务能力库。即要实现关键业务场景，我们需要具备哪些业务能力，这些业务能力如何提供？
　　业务流程和场景的梳理和分析，最终都是为识别和构建能力服务。
　　讲到这里大家可以回忆下我前面谈SOA的文章谈到的，SOA服务目录库规划，SOA服务识别方法，实际上跟这里的观点是完全类似的。
　　业务能力 = 业务组件 + 业务服务API
　　当我们梳理完一个完整的业务场景后，我们需要给出一个匹配的业务解决方案，而这个业务解决方案核心就是业务能力组件的组装和编排。
　　我们希望回答的问题就是，一个完整的业务场景的实现过程就是业务能力组装，编排和复用的过程。
　　业务架构重点2-领域建模
　　在白皮书里面将领域建模的内容全部放到了业务建模里面，实际上完整的领域建模应该同时跨越了业务架构和应用架构，并实现了业务和应用架构两者的融合。
　　领域建模我在前面有专门文章说明，在这里不详细展开。
　　但是还是要强调下，即当你去梳理业务流程，业务活动或业务操作的时候，比较容易识别出关键的业务事件，包括通过业务操作或事件来识别需要具备的业务能力。但是你必须要回答一个关键问题就是哪些业务能力应该放在一起，放在一个大的业务组件里面 ，以确保你划分的业务组件之间本身是松耦合的。
　　这个实际上是比较难的分析过程，往往也需要多次迭代。
　　对应到领域建模里面的上下文边界分析，业务子域的划分。当业务子域划分完成后，实际上大部分的业务组件也就识别定义清楚了，包括各个领域对象究竟归属哪个业务子域也清楚了。最终业务子域变化为业务组件，业务子域之间的交互和协同变成业务组件应该提供和暴露的API接口服务能力。
　　通过流程建模，业务建模和领域建模的结合，共同完成了业务解决方案的设计过程。
　　总结来说就是解决方案的整体设计过程如下：1.识别和提取共性业务。
　　2.对共性业务进行流程建模和领域建模。
　　3.进行基础能力和扩展点设计。
　　4.进行能力组件设计。
　　5.基于通用流程，将共性业务中包含的所有基础能力、扩展点和能力组件封装定义为解决方案。
　　也就是说业务架构设计阶段，基于业务和流程驱动，不仅仅是要识别业务能力，同时要将业务能力，业务对象归集到不同的业务组件或能力组件中。同时在从底朝上去模拟验证，你已经识别的能力如何去组装或编排来完成业务场景。
　　应用架构设计
　　应用架构的核心关注点是业务需求是由哪些应用承载的，它们与用户是如何交互的，它们之间的关系以及是如何交互的，它们访问或变更了什么数据。
　　应用架构的设计主要以应用（Application）的设计为核心，向外围可以延伸到平台型企业架构对于应用分层，分组的设计。例如大家关注的以微服务为代表的分布式应用架构，以及此类架构模式下的常见问题，例如微服务如何划分如何组织，都是应用架构在这个粒度需要关注的问题。
　　同样，以应用为基准，向内部延伸又会涉及到应用内部的架构设计。例如常见的应用分层设计，领域驱动设计中提到的六边形架构、洋葱模型，包括领域对象的详细建模与设计，都是在应用架构这个粒度需要关注的问题。
　　应用架构重点1-分层设计
　　应用架构设计实际是业务架构的进一步延伸，在当前业务能力平台化和服务化思想下，应用架构设计的一个重点是分层设计，分层设计中体现前端应用和后端能力分离。
　　在业务架构规划设计中梳理清楚了两个关键点：其一是完整的业务流程和场景是如何的
　　其二是需要具备哪些业务能力来组装支撑这个业务场景
　　那么第一点更多应该对应到前端应用设计，这个前端应用设计重点是搞清楚前端展现形式，界面交互行为，以及具体的能力如何组装。第二点则是核心的中台能力设计，需要搞清楚需要规划设计哪些应用组件，每个应用组件暴露哪些API接口服务给前端应用使用。
　　当然对应前端应用设计和后端能力设计都会涉及到数据模型和数据库设计方面的内容，但是前端应用涉及到的数据更多是该应用的私有数据，而后端能力中心涉及到的数据则是一个可共享，可复用的共享数据中心。
　　应用架构重点2-API接口设计
　　对应业务架构设计中规划的业务组件可以对应到应用架构中的应用组件，那么业务服务可以对应到应用组件中的应用服务。
　　在业务架构设计的时候实际我们只关心一个完整的业务流程或业务场景的实现需要哪些业务组件提供哪些业务能力来支撑并组装，同时在这个过程中业务组件之间需要进行哪些协同和交互。
　　那么到了应用架构设计阶段业务组件之间的协同和交互就变成了应用组件之间的接口，因此在这个地方需要进一步进行API接口的定义和设计。
　　在当前应用架构微服务化的思路下，更加强调了应用开发过程中的前后端分离开发。即使同样一个应用组件，其前端应用界面和后端能力提供也是分离的。也就是说这个时候存在两类的接口需要设计和定义。其一是应用组件和应用组件之间的接口，其二是应用组件本身前后端分离后的接口。
　　数据架构设计
　　数据架构描述的是企业经营过程中所需数据的结构及其管理方法，其目标是将业务需要转换为数据需求。
　　值得一提的是，数据架构不等于数据中台，数据中台是一种企业架构设计的整体结果，包含了不同视角（业务、应用，数据、技术），而数据架构是数据视角。良好的数据架构规划和设计，为数据中台以及所代表的数据驱动运营、数据驱动业务都奠定了好的基础。
　　数据架构设计重点1-数据库拆分
　　传统的企业架构设计中，数据架构遵循了数据域的划分，数据概念模型，逻辑模型和物理模型的设计。还包括了主数据的识别，主数据的规划和设计等。那么在新的企业架构规划设计中，特别是微服务架构下，数据拆分将成为数据架构规划设计的一个重点。
　　我们关注的重点不应该是数据，而是首先应该是领域对象。
　　领域对象在识别出来后，重点是要将其划分到不同的业务子域，这个时候在领域对象转变为实现层面的数据对象或数据表的时候，才能够有明确的Owner概念。
　　数据架构设计重点2-数据服务提供
　　当数据库进行了拆分后，可以看到本身是导致了大量业务需求实现的时候跨库操作。为了减少上层业务功能实现的复杂度，可以考虑构建分布式的ODS库，这个库再一次将拆分后的数据集中在一起，方便提供集中化的数据服务能力。
　　在数据中台规划建设中，会谈到数据中台本身两个作用，其一是数据服务能力实时的反哺业务，其次是数据支撑大数据分析和决策。
　　不论是上面哪一点，都可以看到首先需要构建一个分布式的ODS库，这个重新集中共享数据后的数据贴源层，才能够提供共享数据服务能力。
　　技术架构设计
　　对于技术架构设计我这里不准备太展开来谈，只强调下里面的一些重点。
　　传统企业架构规划中的技术架构设计更偏于IT基础设施架构规划设计或者IaaS层私有云平台规划设计。而在当前云原生整体技术发展演进中，体现出几个变化点。
　　其一就是技术架构规划本身应该从IaaS资源层走到PaaS服务层，在技术架构设计中去考虑技术组件和技术服务能力的提供，中间件资源池能力的提供。
　　其二就是应该动态地来看整个技术架构规划设计，技术架构应该覆盖软件应用从研发到运行，到运维监控的全生命周期管理过程。也就是说类似微服务开发框架选择，技术组件，容器云的运行环境，后续的IT监控治理等都应该纳入到技术架构规划设计中。对整体架构框架的再思考
　　在我去年思考中台规划，微服务架构规划演进中曾经谈到过传统企业架构规划方法进行改造，重点是业务架构和应用架构合并，当时给出下图：
　　从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。
　　今天结合ThoughtWorks对现代企业架构框架的内容，对企业架构中业务架构，应用架构，数据架构，技术架构之间的关系进行重构，如下图所示。
　　实际在我谈业务架构和应用架构合并的时候就一直在强调业务架构和应用架构本身是一体的，但是确实业务建模和应用架构本身存在差异。因此新构图仍然保持了业务架构和应用架构两个内容，但是从上图可以明确看到两者之间存在一一映射的关系，即：业务流程和场景-》前端应用构建和编排
　　业务能力-》API接口
　　业务组件-》应用组件和微服务
　　而对于数据架构实际应该是横跨了业务架构和应用架构两个领域的内容，数据架构的核心将变化为领域对象建模。即业务架构分析出业务对象，将业务对象抽象为领域对象，到了应用架构和功能实现阶段，领域对象进一步细化为具体的数据对象和数据库表。
　　欢迎关注：@人月聊IT
　　分享数字化转型，企业架构规划，云原生，思维和个人成长类文章。公众号同名，可以搜索关注，文章每周一，三，五定期更新。