2.3 比较结果阐述
结合这些比较对象，笔者总结了一张包含主要企业架构理论的比较图，如图2-1所示。
图2-1 企业架构方法论比较
图2-1中连线建立的依据主要是方法论出现的时间联系或者方法论自身在相关文献中对架构间关系的说明。需要注意的是，连线并非为方法论建立特定的关系，严格来说，方法论在各个比较维度之间的非特定联系要比笔者列出的更加广泛，比如，同一种方法的业务架构设计对应的实现方式，在SOA与微服务之间的选择就可以非常灵活。
2.3.1 业务架构视角的比较
从业务架构视角来看，Zachman框架是第一个提出全面、多视角看待企业信息系统架构的方法论，该框架主张从整体看待企业的所有业务，包含自上而下的设计路径，尽管Zachman框架中各层之间的联系并不紧密，但它依旧指出了架构的一大价值在于基于架构元素之间的联系做出更合理的架构决策。TOGAF继承了这种多视角审视企业架构的思路，并明确提出了“4A”架构理论，该方法论也是自上而下整体设计的典型代表。在TOGAF之后，考虑到企业整体架构设计的复杂性，对于如何构建企业整体架构出现了思路上的分歧。
1.兼顾整体和分段的设计思路
诞生于2002年的FEA提出了“分段架构”的设计思路，即不同领域构建不同的业务架构，所有架构共同组成企业业务架构。这相当于对各个业务领域采取了“分而治之”的思路，但是总体架构依然是可以存在的。2004年，基于FEA的思路又诞生了别具一格的DoDAF，其采用元模型的方式，以叠加的方式构建整体架构，但会通过同一个元模型形成不同领域的架构约束，并依据元模型进行数据层面的标准化管理，这就形成了一个有统一指导的构建分段架构并进行企业总体集成的方式。这种通过元模型构建的架构也成为美国国防部2020年“新数据战略”中提及的“敏捷架构”的基础。
2.严格分段的设计思路
诞生于2003年的DDD采用了非常细分的“限界上下文”设计模式，将复杂业务领域分解成很小的“限界上下文”来应对复杂性问题。前文介绍过，DDD领域的两位代表大师都不太信任“自上而下”的设计模式。但是，无论是考虑到领域架构设计最终会演变成企业架构设计这种自然倾向，还是数字化转型这种非常需要“自上而下”指导的时代级需求，架构设计都必须考虑企业层面的问题，所以，近年来也出现了在原有DDD理论模式上添加企业层设计的尝试，但是目前尚未有成熟理论出现。因此在这个维度上，暂时还是只有DDD这一种方法论。
3.传统的整体视角
整体视角符合多数企业，尤其是传统企业的思维习惯，而传统企业目前依然在企业总量中占绝大多数。这个视角上陆续出现了CBM、中台、BIAN和EBA理论。CBM是IBM公司的业务能力组件模型，从价值链视角将企业业务能力分解成能力模块，也属于典型的“自上而下”的整体设计。中台源自国内互联网企业的实践，尽管被视为“自下而上”的设计模式，但是实际上，所有的中台架构图都具有明显的企业整体架构特征，而且在从互联网企业向传统企业推广的过程中，也很难脱离“自上而下”的业务梳理过程。BIAN也沿袭了从价值链视角将企业业务能力分解成能力模块的思路，属于“自上而下”的整体设计，但是更提倡网络化的服务串接，因此也更适合开放银行理念的实践，并在欧美获得了一定的支持。EBA也是“自上而下”的整体设计，从战略延伸至业务活动，并且强调独立使用业务架构来提升业务思维的结构化水平，适应数字化转型对业务底层思维变化的要求，也明确提出将原来的业务架构与数据架构整合考虑，在其实践过程中，数据模型被包含在了企业级业务架构设计中。
综上，在业务架构方向上，对企业进行整体设计依然是业务架构设计理论发展的主流方向，但是兼顾整体和分段的思路也有一些良好的实践，因此，主流的整体设计模式要在业务架构与技术的衔接、架构设计周期及粒度灵活性上进行适当的改进，以提升设计效率，并为行业级标准化模型的建立做出贡献。
2.3.2 加入应用架构视角的比较
单体是“古老”的应用架构。其实单体并不意味着不好，只有当单体系统不满足业务需要时，单体式应用架构才是有问题的。
单体之后最有影响力的应用架构风格是SOA。它设计能力的成熟大约是在2004年到2008年，这期间关于SOA的构建方法论已经足以指导实践了。
SOA之后，为了解决企业服务总线（Enterprise Service Bus，ESB）等SOA模式中存在的一些对于具有高并发、可扩展需求的复杂业务系统设计的限制问题，微服务体系出现了，并且发展良好。尽管微服务在复杂性方面存在“门槛”，但是在解决扩展性方面还是很有效的。
数字化时代大规模软件生产应当采取行业级标准化构件的生产方式，通过减少同类企业间大量可避免的重复建设，让企业集中精力思考如何构建能够形成有利于竞争的关键性差异的设计。
一般在企业架构设计中，业务架构设计之后的工序就是应用架构设计，不同方法论倾向于不同的应用架构模式。
Zachman框架诞生太早，主要用于单体设计，那时没有其他更好的架构风格可供选择。当然，这并不意味着Zachman框架不能适配其他应用架构风格，主要还是取决于使用者自身对方法论的理解。
TOGAF、CBM、BIAN在各自的指南中都比较推荐采用SOA架构，虽然它们也都可以适配其他架构风格。EBA虽然极力倡导建立行业级标准化构件，但是其诞生依然是基于SOA实践的。
由于中台源自互联网企业，因此其诞生环境本身就是偏向于微服务架构的。但是，最近一些中台实践者发现，在向传统行业推广中台的过程中，SOA的异构集成能力很利于处理企业遗留系统，因此钟华在其中台新书《数字化转型的道与术：以平台思维为核心支撑企业战略可持续发展》中，对SOA的价值给予了高度的肯定。中台、BIAN、EBA目前均在不同程度上提倡建立基于行业级标准化构件的应用架构，这是未来的方向。
虽然DDD方法的诞生早于微服务架构，原本是为更好地开展敏捷过程而设计的，但在实践上却是由于与微服务架构的结合能力而真正受到重视的。
FEA、DoDAF没有明确指向某种具体的应用架构风格，尤其是DoDAF，因为它并不给出明确的系统设计解决方案，而是给出方案的约束，因此也不会有明确的应用架构指向。
综上，尽管当前开发领域经常讨论微服务，但是企业架构方法论还是指向SOA的居多，这一方面与大部分理论的诞生时间有关，另一方面也与企业转型过程中企业架构设计经常要考虑对遗留系统的处理有一定关系。应用架构设计还是要考虑一些实施的约束的。
严格来说，业务架构与应用架构之间是松耦合关系，但是正如笔者在讨论BIAN时所言，仅从提升设计效率的角度讲，我们也需要将业务架构与应用架构之间的结合设计得更紧密一些，正如DDD所表现出的一些特性。此外，随着数字化的发展，业务架构中的绝大部分内容都是要落实到系统设计上的，而应用架构中的模块或者服务的切分问题一直没有被很好地解决，主要还是依靠经验和摸索。乐高积木式应用架构设计理念迟迟未能实现，笔者认为最主要的原因就是业务侧没有很好地将其自身结构化，并深度参与到系统设计过程中来。
目前数字化转型中的一种思想认为，所有业务都有理由被“重做”一遍。如果真的“重做”一遍，笔者建议最好能够先由业务侧采用业务架构思维将业务重新结构化一次，将重新结构化的业务架构与应用架构紧密衔接，成为业务和技术都能理解的“乐高积木”，而不是仅将两个架构局限在需求与实现之间的映射关系上。
2.3.3 加入技术架构视角的比较
技术架构仅选取了集中式和分布式这两种分类方式进行比较。当然，分布式包含多种不同的实现，比如头部互联网企业当前实践的“逻辑单元化”等，但是作为一种粗颗粒度的比较，笔者认为无需细致到不同企业的具体实现方式上。
业务架构通常不会对技术架构提出很直接的要求，但是业务需求中对非功能性需求的考虑会影响到技术架构的选型，比如面对大业务量的高并发、可伸缩需求，一般会采用分布式系统。但通常来讲，业务架构会影响应用架构，而应用架构往往与技术架构有一定的结合。
单体应用出现的时间早，因此可以直接对应到集中式架构。分布式架构的逐渐成熟应该是在2000年～2008年，CAP理论和BASE理论的提出让分布式架构的设计更加实用。SOA理论也在这个时间段逐渐成熟。考虑到很多SOA案例与大型主机之间的联系，SOA架构案例往往倾向于采用集中式，但实际上SOA架构也是可以采用分布式架构的，所以图2-1中未对SOA与技术架构进行明确的连线。
微服务架构在互联网企业的实践中往往是与分布式关联在一起的，而且在将微服务技术输出到传统行业的过程中推荐使用的也往往是分布式架构。
未来的行业级标准化构件架构模式，考虑到系统扩展性的要求、平台化的发展以及大量遗留系统被逐渐淘汰，也推荐使用分布式架构。
其实，集中式架构与分布式架构没必要论个“高低短长”，更多还是要从实际需要出发。从大的趋势上来讲，分布式架构的确表现出了较强的主流趋势。
2.3.4 加入软件过程视角的比较
瀑布和敏捷其实并没有绝对的优劣之分，当需求明确时，瀑布模式往往效率更高，协同性也会更好；但是当需求模糊，目标不稳定时，敏捷体现出来的试验性特点就比较适合应对项目的风险特征。敏捷和瀑布不能简单用“快”和“慢”来考量，良好的过程管理也能带来效率的提升，架构混乱的敏捷也会有技术债务要偿还。所以，不能片面追求某种指标，而是要从目标、组织和企业文化出发，建立具有适配性的工程管理能力。
此外，敏捷过程在实践中需要DevOps等开发平台、能力的支持，不具备这些平台时，敏捷的效果会大打折扣。而实际上，如果具备这些平台，即使用瀑布模式进行开发，效率一样会获得提升。一些大型银行的实践表明，在开发能力提升、可用资源增加之后，在不改变开发模式的情况下，开发效率也一样会有较大提升。因此我们可以看出，很多大中型银行面对的其实不是不适应模糊需求的问题，而是缺少足够的开发资源应对大量确定性开发需求的问题。很多传统企业也是如此，敏捷过程并不能彻底解决这些问题。因此，不同行业、不同企业在不同阶段需要解决的困难是不同的，不能一概而论。
多数企业架构理论给人的印象都是体系庞大、周期漫长，且天然适配瀑布模式。确实，除了DDD、中台能匹配敏捷过程外，其他架构理论显然更适合瀑布模式。
其实思考这其中的关系更合适的视角可能是将面向首次企业级转型的企业架构设计过程与其后基于企业架构的长期演进管理分开考虑。对于首次转型而言，应该尽量采用全局的视角与合理的周期进行一次完整设计，即架构设计本身是一个瀑布过程。在架构落地过程中可以灵活应对，毕竟没人能保证环境不变，但是完整设计有助于评估变化的影响和应变的必要性，有时对变化的快速适应和对变化的不适应一样，都有走弯路的可能，没有绝对可靠的解决之道。
在首次转型结束、进行演进式管理的过程中，架构本身已经具备快速识别和定位需求的能力，架构思维也可以引导业务人员更结构化、系统化地思考业务，因此架构本身对企业的快速演进已经能够形成助力了。但是，架构设计和管理人员必须清楚，架构管理的本质不是维护架构的稳定，而是面对变化做出合理的判断，这是建立企业架构的价值所在，也是从Zachman框架开始一脉相承的“初心”。对于这一点，一些互联网企业深有感受。笔者经过近些年的观察与交流发现，互联网企业在经过初期的快速发展后，实际上已经走上了一条“重新发现企业架构”的路。
2.3.5 综述
综上，业务架构是各种企业架构方法论中差异最大的部分，业务架构理论上可以灵活地适配不同的应用架构，但是目前指向SOA架构的方法论居多。而在技术架构方面，分布式架构是发展的趋势。对于实现数字化转型而言，采取瀑布模式完成整体架构设计也许更可取，但是在具体实施层面及此后的演进中，可以灵活选择工程模式。
比较务实的方法论研究方式还是以某种方法论为企业实施的核心方法论，在实施过程中不断吸收其他方法论的优点，不断完善对实践的指导能力。在企业架构这类较为“深邃”的领域，频繁切换赛道有可能不利于企业的知识积累，而知识积累恰恰是方法论发展和创新的最基础、最关键的因素。
作为未来的方向，业务架构设计必须整合业务与数据两部分，并基于标准化理念努力提炼行业级标准化业务构件，与应用架构实现更紧密的连接，以支持基于行业级标准化构件开发的应用架构风格。
这种风格在企业内部的实现上依然可以是微服务模式或者SOA模式，但是在行业级层面则可以考虑结合标准化的开源模式。由于采用行业级标准化构件，开发效率可以有更大的提升，也更有利于开放式架构的实现，包括开放银行、开放生态等。
企业不应过于关注行业内同质性业务部分的开发，而应更多关注可以真正产生差异的部分，做合理的“定制化”，否则大部分系统开发费用都被投入“同质化”竞争了。
技术架构逐渐会以分布式为主，而在工程模式上，基于标准化构件的、有总体架构做指导的新型敏捷实践也许会出现，因为这是更符合数字化时代大规模软件生产需要的工程方法。这种敏捷需要区分重大重构和一般性演化，重大重构需要采用规划的方式进行指导，一般性演化则是在已有架构的基础上做局部演进，可以更多采用敏捷过程。
此外，我们应当尽可能用敏捷思维而非某种特定的敏捷过程指导企业工程，即应该更多关注如何在实施过程中基于快速反馈机制形成快速调整能力，而非拘泥于特定的工程模式。在这一点上，无论对待敏捷过程还是瀑布模型，都应当采用一样的态度。
2.3.6 企业架构理论需要持续演进
企业架构目前也存在一些需要解决的问题，这些问题制约了企业架构作用的发挥。比如，业务架构本应成为业务与技术之间的桥梁，但实际上仍停留在技术人员的作业范围内，很少被业务人员了解和感知，也没有被业务人员应用到业务领域中去解决问题；架构设计领域至今没有出现非常好的工具，设计工作都由架构师负责，业务资产、IT资产缺乏有效的管理和连接，这个问题从Zachman框架时期延续至今；由于对项目周期和开发速度过分关注，架构管控工作僵化、生硬，架构的弹性和创造性没有得到关注，反而使架构成了不灵活的管控工具。这些现象导致了对企业架构价值的轻视，甚至产生了不正确的架构理念，限制了企业架构理论和实践的良性发展。
企业架构最重要的价值是要解决业务和技术的深度融合问题，这种融合基于最普通的沟通，让业务和技术能非常简单而直白地“聊”到一起。“聊”到一起需要“共同语言”，语言是人们沟通的工具，而背后支撑语言进行表达的是思维模式。这种思维模式要求既能够被业务人员接受，又要能在日常工作中使用，这样业务和技术在思维模式上才能真正接近。这种模式就是结构化思维，这也是企业架构的核心思维模式。
这种模式并不会过度增加业务的学习成本，因为业务本身也是可以且需要流程化表达的，尤其是当越来越多的业务流程被自动化执行的时候。业务人员也需要结构化地理解数据，因为，数据服务越来越无法像过去那样靠“喂报表”就得到满足了，业务人员需要“主动”地使用和理解数据。流程和数据就是企业架构需要结构化的关键对象，它们的数字化转型过程都需要业务人员深度参与。
当业务人员深度参与流程与数据的结构化，将结构化思维应用到日常工作中时，我们就会发现，此时企业架构思维已经成为数字化时代的“管理语言”，这是成为数字化企业的必要条件。如果企业架构不融入企业管理中，企业就无法在各个层面促成深度的业务技术融合，无法真正用数字化的思维思考，仍然需要用“翻译”去解决业务和技术的沟通问题，使自己处于“数字化管理窘境”。
总之，我们处在一个迫切需要企业架构方法论创新发展的时代，这是帮助所有企业完成数字化转型，乃至完成全社会数字化转型的必经之路。架构的自主可控是企业核心能力自主可控的标志，企业架构方法论也需要实现“道路自信、理论自信”。
目前主流的架构理论中，无论从哪个维度看，国产理论都寥寥无几。我们已经有40多年的信息化建设历史了，工程和架构的创新之路需要我们认真走下去。而这条路的开端，笔者认为应该放在业务架构上，除了技术人员长期坚持的“供给侧革命”外，来自业务人员的“需求侧管理”也是数字化时代必不可少的。