老司机跟你聊聊学习企业架构和业务架构的那些事儿

随着数字化转型的发展，对数字化的认识在国家政策的推动下，已经由一些局部改良、点状技术应用发展到数字中国、数字经济的高度，笔者在最近一系列解读“数字金融”相关高层会议精神的文章中，也提到，数字化是这个时代的特征，银行的数字化就是这个时代的银行的基本特征，这一点放到众多其他行业也是一样的，“数字”就是时代特征，每个行业前边都可冠以“数字”这个定语，其区别主要是数字化程度而已，程度则是由行业特征和技术应用能力决定的。

在这种社会级大潮下，很多企业的数字化转型逐渐提升到整体转型层面，提升到将时代特征由表层应用转化为深入内涵的“业技融合”，转化到真正期望通过对数字技术的应用，实现企业、行业效率整体提升的层面，也就是真正走入到“高质量发展”的层面。对很多企业而言，只要企业是在持续关注效能的提升而不仅仅是粗放的规模扩张，这就是在做“高质量发展”，只要是试图寻找突破原有业务惯性的“新增长点”，就是在探索“新质生产力”，这并不神秘，甚至很自然。

这种发展方式逐渐需要企业重新、全面、深入地认识自己，从对自己“模糊”的印象到“精确”的认识，从“笼统”的管理到“精益”的管理。这种管理模式的变化还同步要求企业的数字化能力可以匹配地支持业务的变化，也就是要“业技同频”，乃至真正“业技融合”。这种融合一定先从管理层的管理思维转变开始，只有对数字化的信任，对数字手段的合理、持续追求，才能带来真正的改变，如同对一个人的改变一样，先从意识、大脑开始，然后是行动、肢体的改变。

系统性思维，或者用笔者常说的全局性结构化思维，正是适应“数字”这一时代特征的思维模式，是该被融入到管理层，融入的企业各层级，业务和技术两侧的思维模式，一个企业内部的融合离不开“共同语言”，而“共同语言”离不开“共同思维”，“共同思维”背后则是“共同信念”，是基于对“数字时代”的信念，而产生对“结构化思维”的信任，再产生对“结构化表达”也就是“共同语言”的需要，继而才是基于“共同语言”模式的沟通效率的提升，也就是“业技融合”，“业技融合”的基础并不是要业技双方都得先充分理解对方做的事情，而是先建立共同的“语言习惯”来提升沟通效率，“融合”说到底是人的融合，要么在一个人身上复合所有技能，当然这又难又慢，代之可行的则是由具有不同能力的人复合在一起，那就需要优先解决沟通问题。不过，不少人讲，结构化思维不好练，尤其是对业务人员而言，其实也没那么难，日拱一卒，定能功不唐捐，反正，又没有不作任何改变就可以完成的转型、变革，只要做的是符合时代发展方向，早晚都得做的东西，那就没有什么真正的困难，总比搞个可回收式火箭容易太多。都讲值得用数字化、智能化把所有行业重做一遍，那连结构化思维都搞不定，这个“重做”是在指望谁来做呢？是在指望别人革了自己的命？

所以，好好研究、推广下结构化思维，尤其是在业务侧推一推，是很有价值的，对业务人员的数字化转型而言，这是必备的基本功，是需要全体业务人员优先学习的，是重塑自己的业务必然会用到的，是值得投入而且真的不会浪费的时间。都说要找“业技复合型”人才，而且也越发意识到这种人才还是只能自己培养，那这种人才最基础的能力是什么？不正是全局性结构化思维吗？这种人才能够提出的、实现业技融合目标的业务解决方案，其基础不正是理清业务问题和技术能力的关系，并将其“复合”到一个方案中吗？无论是否曾经有意识培养过，这种人才的关键能力都是结构化思维能力，如果以前未曾有意识地培养过，那正好现在培养一下，毕竟，人的能力结构没有改变的时候，什么事情都不会真正改变，我们只能是沿着旧路再多走几步。

现在企业、个人都逐渐意识到了这种全局性结构化思维的价值，笔者自己同时从事咨询和培训两个行业，接触到的朋友、客户都对此抱有信心，现在，随着数字化的带动，作为“全局性结构化思维”重要代表的“企业架构方法论”，尤其是其中一直实践不足的“业务架构方法论”的讨论文章、视频也越来越多。这类方法论的发展历经了 30 多年的时间，期间起起落落，褒褒贬贬，说法不一，也肯定会让很多读者看起来“云里雾里”，加上这领域一直以来一大困扰就是“定义”不过关，缺少经得起考验的标准“定义”，所以，关注归关注，迷糊归迷糊，信息多了，未见得就“通透”了，笔者希望借本文，根据自己近十余年的企业架构、业务架构工作经验阐述下自己的一些观点。笔者一直热爱这个领域，从 2012 年有幸作为甲方核心业务架构师参加了一个国有大行六年半的企业架构转型工程以来，自己历经了从甲方到乙方、内资到外资、国企到民营、传统企业到互联网，最后再到独立顾问、一人企业的职业历程，从工作到写书、写课、发行业务架构证书，从企业落地、咨询服务、企业内训等多个视角观察和运用这一方法论体系，希望能将自己喜欢的、思考的、实践的，分享给读者，共同讨论。

一、 企业架构和业务架构方法到底是什么

这个问题挺“虚”，但是很重要。读者也许在这里期待一个严谨的定义，不过，抱歉，没有那么严谨的定义，相对严谨的是“架构”的定义，ISO/IEC 42010:2007 中的将架构定义为：“一个系统的基础组织，体现在系统组件，组件之间及组件与环境之间的相互关系，以及对系统设计和演进进行治理的原理中。”简单的说，就是结构、关系、原则，这三个词概括了架构的主要内容，企业、业务这个都属于定语，也就是通过结构、关系、原则的厘清要去描述的对象，合成词一般都得这么理解。

其实跳出对“架构”的过分关注，在笔者看来，企业架构和业务架构方法就是“观察方法”，所以笔者在自己专门阐述企业架构方法论的《聚合架构》一书中提到“架构观”，套用了“世界观”这个词，“世界观”指的是观察世界的一组观点体系，也就是从多种视角或者视点观察世界来形成一组描述世界的结论，架构也一样，通过一组观点体系（或者叫维度，以结构化观点为主）观察架构设计对象，所形成的观察结论。

笔者在这里非常想强调“观察”一词，因为一谈上架构，大家总愿意对“设计”眉飞色舞，其实大部分架构“设计”中的工作成果都属于“观察”，是在反映设计对象的实际形态，只有当架构师需要改变现状时，才谈得上“设计”，这种“设计”其实也可以说成是架构师引导的对目标的“观察”，因为这种“设计”往往不是架构师可以直接做主的，尤其是在企业架构、业务架构这个领域，业务架构基本上没有“黑盒”，它反映的是企业的业务形态，无论是当前还是未来，其交付成果需要经过业务侧认可，变更也需要业务侧认可，所以，“观察”的成分远高于“设计”，要坦诚地面对大千世界，做个“谦逊的架构师”。这一特质的好处是，它决定了业务架构方法很简单，很易学，虽然不代表很容易在企业内实践，但就方法而言，确实不难，同时也决定了一个优秀的业务架构师对业务了解并非是第一位的，或者说是充分条件，但不是必要条件，一个优秀的业务架构师应该比一个优秀的业务人员更容易切换业务领域才对，结构化的观察能力才是充要条件。笔者自己不但原来在甲方做实施时换过多个业务线，现在更是努力跨越多个行业去做咨询和培训。

此外，业务架构并不一定非要以系统设计为目标去做，因为，业务架构是可以独立用于业务管理的，它是更有“数字时代”特征的业务管理方式，就好像之前很多企业都做“流程管理”，现在可以将其升级为“业务架构”管理，因为较之传统“流程管理”，它可以通过更加结构化的方式将流程、数据同时管理起来，并将流程和数据结合起来讨论更适合于从“数字”角度去理解的企业结构，也就是说，它本身就可以用来单独研究业务问题，只是因为结构化程度高，并且其结构化基本原理符合系统设计基本原理，才可以用来做推动“业技融合”的企业架构方法。

所以，当我们谈到企业架构和业务架构方法时不要一步跳到系统规划方法、跳到对设计的关注，我们应当首先把它作为一种结构化的“观察方法”来学习，学习如何用全局性、结构化的方式去描述一个复杂事物，当我们了解了这个事物的结构时，才能更好地研究对事物的调整、演进。可能很多人会觉得对于现在这个充满挑战的“不确定性时代”而言，规划的方式、全局的思考模式有些慢、不合时宜，其实读者只需要问问自己，是希望糊里糊涂地“碰出运气”，还是希望多少有些“掌控”，时代其实一直都在变化，没有静止的年代，车马很慢的时代也一样有“不测风云”，还是不建议大家听着别人“闯荡”的江湖故事打光自己手里的“真金白银”，老祖宗讲的“三思而后行”是值得牢记的，想想“深度思考”到底是什么，该怎么做。企业架构和业务架构方法也许有些慢，尤其是在企业、实践者最初接触的时候，学习过程、应用过程都有一些问题要克服，会有些缓慢的地方，但正是这些“缓慢”造就了你的基本功，而正是踏实的基本功让你能够更好地观察、设计。

正因为如此，对于企业架构和业务架构方法的学习也不一定非要在项目上，笔者在企业内训中经常讲，作为一种对结构化思维的训练，学习者可以在很多方向上练习，看电影的时候注意电影的结构，读书时注意书的结构，欣赏诗词注意诗词的结构，搞收藏时注意对藏品的分类比较等等，只要你不是喜欢“眉毛胡子一把抓”的类型，那就可以在很多事情上练习结构化思维，这远比只通过项目练习机会要多得多，也有助于养成更好的思维习惯。这个世界上至少目之所及没有无结构的事物，看得见的，乃至一些看不见的，都有结构，学会观察结构的方法，这是学习架构方法的基础，也是架构方法的要去探索的本质性的东西。

记住，学架构主要就是在学习观察世界的方法，而且是基于共创的方法，在企业中的架构实践往往不是一个人，甚至不应该是少数人的工作，像笔者这种咨询顾问可以是“独行侠”，但在企业内部的实践绝不是这样，所以，我们是在学习一个观察世界并基于共创最终会去改变世界的方法，企业要培养的不仅是几个精英架构师，而是全局性结构化思维对整个企业的渗透。

二、 该学什么样的企业架构和业务架构方法

了解了在学什么，接下来自然是看看怎么学，学什么样的东西合适。之所以这么讲，毕竟这套方法论从缘起至今，也有 30 多年了，期间，Zachman 框架、TOGAF、DoDAF、FEAF、CBM、中台、BIAN、MEAF 等等，包括谈起微服务经常必不可少要去聊的 DDD，以及笔者自己基于实践写书提出的企业级业务架构、聚合架构方法论，传统的、新锐的，有实践，有想象，方法各有千秋，讲者各有所长，经验各有深浅，视角各有不同，如百川奔流，都汇集到读者这个“大海”，在读者心里搅起波涛暗流，忽而清明澄澈，忽而深不见底。

视角多样，有助于学习，但也增添了理解上的难度。这么多可选的项目，到底该学什么样的呢？文章这部分笔者就和各位一起做个选型探讨吧。

（一）要选择具有充分实践基础的方法论。这句很重要的废话，对学习方法论来讲却非常难鉴别，因为尽管企业架构方法论有 30 多年的历史了，但就实践而言，大部分时间段里都是不太充分的，并且行业分布也不平均。说到这一点，就翻翻旧账吧。企业架构方法论诞生在国外，Zachman 框架是第一个，但是实践上，国外的大型企业往往借鉴企业架构思想体系，进行“缺啥补啥”的操作，或者用于梳理高阶框架，比如 BizBOK 这样的纯业务架构方法论，还是不做细节梳理的，这方面不同的方法论也是各有主张，各有道理。所以，在企业架构框架内完整进行业务架构、数据架构、应用架构、技术架构整体设计并由其驱动大型工程的非常少，这也是很多人抨击企业架构的原因，一个非常宏大的设计远景，逻辑通顺的设计方法，但是鲜有明确的设计实例。其实就上个世纪企业架构诞生时的条件而言，哪怕是在本世纪前几年，确实很少有企业有能力进行这样的整体设计，就算“勇敢”地做了设计，也很难找到足够的技术资源进行实现，那个时候，哪怕是银行这样有实力的甲方，也没有多少 IT 资源敢去尝试对核心业务系统进行完整的重构，这是很现实的问题，说起来跟人工智能的发展有点儿像，逻辑对，算法也可以，但是算力、存储、数据都不行，硬实力扛不住。人工智能后来的突破正是有赖于硬实力的发展，企业架构也是，现在很多企业可以这么干了，是因为大家的 IT 资源尤其是人力资源这块，比那个时候要充裕多了，这么多人了，该想的就不是各自为战、怎么快速搞个系统的事情了，而是大家怎么协同工作，做的系统又怎么协同起来，硬实力和软目标都在寻找企业架构这类方法，提升对大量 IT 资源、大量业务系统带来的复杂性的管理能力。既然硬实力和软目标是这样的，那要找的方法就应该有充分的实践基础。

读到这里，读者可能觉得绕到死胡同了，本来就缺实践，还要找有实践基础的，怎么找啊？这方面国内反倒是有些优势，因为国内企业由于对信息化实践的持续关注，积累的业务系统越来越多，所以在最近十余年的时间里一直不乏有大型企业尝试这类方法论的实践，笔者自己了解到的，包括航天制造、电力资源、汽车制造、消费品行业等都有，其中最有深度和特点的还是金融行业，尤其是大型国有银行，国内六家大型国有银行都不同程度、不同形式地开展了企业架构工程，在实践上各有创新，所以，学习的话，尽量找这些行业实践过的方法资料去学。企业架构通用理论可以用于对整个体系的学习，需要了解更多实践经验的话，就要找行业资料了，两者搭配学习。另外，就总体而言，实践过的行业还是很少的，所以，不要总想着找跟自己行业对标的去学，很可能你会无标可对，无标可对也可能是好事儿，笔者之前在甲方中的深入实践就是基本属于无标可对的，这种环境下，最大的好处就在于你可以充分关注自己的诉求和目标，不用总是琢磨别人为什么这么做，总琢磨这个，尤其是耗费精力太大的话，得不偿失。

选择有充分实践基础的方法论，还有一个鉴别技巧，就是对方是否有基于架构设计成果推动项目实施落地的经验，是否对架构设计、架构协调、项目实施、架构工作体系建立、方法改良等都有一定的了解，而不是只能阐述某一个环节，前后没有一个完整的工程经验串联起来，经常会说着说着变成基于自己工作经验对企业架构的“想象”了，因为有工程经验的人绝对不少，但是有这类项目真实、深入、完整经验的确实非常少。这类项目很“矫情”，项目经验不完整、项目体量不够大、项目周期不够长，那可能遇到的“场景”就不太齐全了，所以，说着说着，就成了“好像”、“大概”。这个行当里，一群没怎么做过的人给另一群压根儿没做过的人讲，是非常常见的现象。不过，笔者并不是有意反对大家在没有足够经验指引的基础上开展架构工作，毕竟一切皆可探索，凡事皆有创新，这里只是就事论事，提个醒而已。

企业架构里其实还有另一块非常重要的内容，但是往往会被忽略掉，而它又恰是企业架构的核心工作，那就是对企业战略的落地拆解，企业架构的最高目标是服务于企业的战略落地，但是很多企业觉得这个事情费时费力不讨好，战略又经常在细节层面说不清，为了“保交付”，经常会压缩掉这部分，其实这也是检验方法论实践基础的一项重要内容，没梳理过战略或者目标的，做的就是不完整的企业架构，也就是只做了偏向于现状的架构，没有目标架构，没有架构演进部分，而现状架构的梳理有一些可以“讨巧”的方法，能够规避开复杂的项目组织问题，使架构项目演变成一个轻量级项目，这是笔者自己做顾问时也会采用的方法，但是，放到这部分来讲这个内容，是希望大家了解到战略的价值和什么才是有完整实践基础的方法论。

总而言之，有没有以企业架构方式驱动的大型企业级项目为基础，从战略到架构到实施到体系转换的完整经验，是需要在学习之前做“选型”考虑的。

（二）要尽量选择流程和数据相结合进行架构分析的方法论。这里选择的用词是“尽量”，因为大部分常见的对企业架构、业务架构方法论的介绍，都是采用 4 个架构（业务、数据、技术、应用）分开介绍的方式，而企业架构实施中常见的一个问题又恰恰是如何让 4 个架构融合一致的问题。4 个架构融合一致并非是分开做完 4 个架构，然后互相勾勾挑挑就算融合一致了，如果这样能解决问题，笔者也就不需要在这里专门再讲这个事情了。

4 个架构的融合要求架构设计方法论要提供可融合的设计逻辑才行，传统上一般把数据架构设计放到信息系统设计的范畴，也就是将数据架构和应用架构合起来作为技术上的工作内容，但是根据笔者之前项目实施的经验，这样做不太容易真的做到融合，尤其是这种设计方式会很自然地与技术上以前的工作习惯，也就是数据设计方面不怎么考虑逻辑模型，或者即便做了也是数据设计人员自己考虑不怎么融合到总体设计中，更常见的则是直接走到库表设计，所以笔者接触过的大多数企业都没有逻辑级数据模型，逻辑级数据模型的缺少实际上是少了架构融合中的关键一环。

这个问题我们还得再往前倒一倒，传统的企业架构、业务架构或者系统分析，大多数都是强调业务分析中的流程分析，也就是用过去的模式做的业务架构，其主要部分就是流程的结构，然后很多人也都讲，理清楚流程分工和关系，推导系统功能模块，所以业务架构中经常出现业务功能这个词，就实操而言，从流程结构直接划分功能模块不是太“科学”，或者说不是太“准确”的，比如，流程经常有相似的，这些相似的流程到底是不是一个流程，或者能不能整合成一个流程，是不是共用能力，流程分析自己不是总能回答这些问题，流程在一起也不意味着后边的系统实现就一定在一起。

此外，传统流程分析是不重视颗粒度问题的，或者说它也没有办法很好地界定颗粒度，尤其是细粒度元素的颗粒度，比如一个流程图中的那些小方块，也就是任务，也有方法中称之为步骤，到底该多大，如果流程设计本身不能很好地回答这个问题，那这张流程图对系统设计而言，只能是过程说明，无法成为结构说明，也就是不能向后延伸对模块、服务、微服务的划分指导。

要解决这些问题，就不能在业务架构部分只重点关注流程的结构，还要关注数据结构。可能有些熟悉流程分析、流程管理的读者会认为，之前的流程也关注了数据，但是那个关注的是“业务信息”，也就是偏向“单证书表”的外在形式，而不是其中蕴含的“业务对象”，“业务对象”就是常说的逻辑级数据模型中的数据实体，是一个一个独立的业务处理对象，而不是各种信息混在一起的一张表。

读者可能无法一下子直接理解到为什么对在“单证书表”上不行，对在“业务对象”上就可以，其实这也是为了更准确地界定到底业务能力是什么，很多设计都讲我们要对着业务能力设计，要实现业务能力，其实对业务能力说的比较好一些的还是 BizBOK 给的说法，能力是要有目标对象的，也就是这能力到底用在“谁”身上，能用出什么效果，当然，为了搞清楚、实现它，你还得知道它发挥作用的过程，那么总结起来，就是知道能力的作用对象和作用过程，以及一个效果预期，也就是目标，这就是能力，其设计基础离不开过程和对象。“单证书表”往往包含了一堆的对象，所以只对着“单证书表”看，就很难找到可独立、可扩展的设计对象，没法为后边设计要求的模块、服务、微服务的独立性、可扩展性提供分析基础，所以，在业务架构设计阶段，就必须带入逻辑级数据模型分析，至少要做到实体级，而且是跟流程一起做，结合做，流程中的每个细颗粒度元素要如何做，得结合具体的业务对象一起判断，这样设计出来的流程、数据是可以为后续应用设计中各元素的切分提供参考依据的，而且也为业务侧自己定义业务能力，分解企业战略提供“科学”的、“清晰”的操作方式。

基于业务对象的分析还有一个好处就是它符合系统设计的基本原理，系统设计也是根据数据聚类行为，也就是关系相近的数据放在一个系统里，再将与其相关的行为定位到这个系统中进行实现，所以，业务对象，也就是数据实体是整个设计联通的关键。数据实体可以更好地帮助流程进行整合、优化，处理相同对象的流程就是相同或者可以整合、公用的流程，根据数据实体划分的流程颗粒度，可以将流程和数据结合去推导应用侧的设计，这样业务、数据、应用三个架构才有可融合的设计逻辑，不能只是流程、数据、应用各干各的，互相看看理解一下就行了，那样是没有充分融合的逻辑基础的。

随着大家对数据要素越来越关注，这种业务架构设计方式，也能够帮助企业更好地界定、利用数据要素，所以，笔者前文才称这种结构化分析方式是业务人员数字化转型的基础，也是“流程管理”需要升级为“业务架构管理”的原因，业务架构管理才是更有“数字”时代特征的业务管理方式。

对 DDD 情有独钟的读者可能会觉得，那这个层面用 DDD 可以不可以啊，这方面确实有这样的探索，我的好友张逸老师在他的专著里，另一位好友，TW 的王健老师在他们的 MEAF 中，都有类似的主张，传统方法分析活动级及以上的业务，从任务开始的细化部分转入 DDD 方法；中台也有对 DDD 方法的参考，虽然不是完整引入。其实这里是可以从权的，设计方法就像“方言”，它是会考虑使用者习惯的，这就不仅是技术侧的使用者，还包括业务侧的使用者，DDD 是很有效的、直通应用设计的方式，不过它的难点则在于向业务侧的导入，也就是，在方法选择上是一个方法做到底，还是两个方法合着用，这没有对错问题，只有从权而已。

好了，根据这个部分介绍，读者也可以“尽量”判断下哪些对方法论的介绍是有助于实现业技融合、架构融合的设计方法，那些介绍还是过去相对分离的思考模式。

三、 千万不要忽视比设计还要更难的东西

在笔者自身的经验看来，企业架构、业务架构都不是什么要上九天揽月的高难度方法，笔者在自己的书中也多次提到，它的复杂属于“规模复杂”，也就是设计范围大带来的规模复杂性，要考虑的范围比较宽，要处理的协同量比较大，加上有标准化的心但是没有标准化的“尺”，所以操作上比较繁琐、折腾，但是这并非企业架构、业务架构独有，只要是在处理这么大范围的问题，换什么方法都一样。

但是这些还不是最困难的东西，最困难的是组织方法，怎么让一个企业能够动起来用它，企业架构，之所以叫这个名字，就说明它不是架构师的架构，而是企业的架构，企业整体参与度越低，它就越不像是企业的工作模式、思维方式，而只是一个用途有限的设计图，它也许带来了一时的设计改进，但是很难成为一个企业内在的持续竞争优势，读者可能觉得又扯远了，这是什么优势啊？这就是兵法有云的最基本的交战原则，“知己知彼”中的“知己”，特别是数字时代的“知己”，清楚知道并随时可看自己的业务结构，以及对应的 IT 结构，就像有一个可以模拟推演的作战沙盘，能够快速、全面地分析重要决策的实现路径和内外影响，这就是数字时代的“知己”，也是企业数字孪生、管理数字孪生的基础。所以，有效调动企业的参与是比设计更难的事情。

已有的工程组织模式中，业务侧主导并且全面推动的、技术侧主导需求统筹为主的、联合主导分线推进的、局部试点的，各种模式都有，这些组织过程、项目组织结构设计也是需要去深入思考的，不然，空有一身本事，没人配合你玩耍，就只剩孤独寂寞冷了，前文特意说过“共创”这个词，这个词很重要的，一个人的广场舞可能很没意思吧。

笔者在自己的项目中曾经回答过客户这样一个问题，客户关心企业架构如何落地，其实企业架构落地的问题在于是否能将企业架构驱动 IT 开发的管理模式落地，而非只是落地架构设计图，只有将企业架构渗入到 IT 管理乃至渗透到业务管理中，企业架构才能自然落地，很多项目上出现过架构一套，实施一套的情况，其表层原因是大家对架构设计理解有分歧，而深层原因则是架构驱动的 IT 管理、业务管理体系没有真正建立起来。

除了组织之外，在设计过程中能够动员参与人员真的把只是提炼出来，而不是只把业务过程贡献出来也很重要，一个系统到底是不是有潜力的系统，要看其中包含了多少业务知识，这个在梳理过程中是要努力发掘，加强引导的，毕竟提炼知识是个“烧脑”的活儿，需要持续盯着。未来大模型工具会逐渐加入开发行列中，当复杂代码的实现逐渐被“屏蔽”，我们更多的精力是要转移到业务知识萃取上了，如何让业务系统可以教人办业务，而不是人学会了办业务再去用系统，这是 B 端软件要解决的 “最大体验”问题。

四、 利用零代码工具加强理解

这部分看似有点儿跑题，不过并没有，这是笔者最近对企业架构研究和学习的体会，由于偶然的原因，今年接触到零代码工具，也认识了一个新的合作伙伴，伙伴云，在他们的帮助下，笔者开始了基于零代码平台设计企业架构学习工具的尝试，不愧是零代码，确实是只要逻辑想清楚了，动起手来真的很快，目前笔者设计了五六十张架构元素信息和关系表，算是搭建了一个架构学习工具的小框架，后边还要在“装修”上花点儿功夫，然后就可以出来“面市”了。笔者觉得这个小工具除了学习，也可以做一定的架构设计和资产管理用，后续笔者还会考虑将这个小工具跟我另外的合作伙伴，数孪模型科技、优诺等专业工具厂商的高端工具进行数据对接，方便使用者日后“消费升级”。

从笔者的经验看，真的可以基于零代码工具，以数据实体为核心建立起一个连接 4 个架构的简易工具，这个工具的设计过程完全可以成为学习者认真思考架构内核的过程，也体现了笔者前边说的，逻辑级数据模型的重要性。为架构建立架构，而不是只关注设计方法、组织过程，会让学习者更深入内核去理解架构，能架构别人总得先能架构自己吧，不然为啥很多方法都有元模型这个稀奇古怪的东西，毕竟，如果连自己结构都说不清，怎么能教会别人理清结构呢？零代码工具又完全没有了编程的困扰，一心只关注“观察”、“思考”、“设计”，实现速度也快，是学习架构的好帮手。笔者在企业内训课程上也跟技术人员推荐过零代码工具，笔者认为搞全代码开发的人，偶尔用用零代码工具挺好，不写码了，少了个重要手段，反倒会更关注对设计对象的识别了。

好了，本文就到这里，后续笔者有一系列关于企业架构、业务架构基础知识的文章会在 InfoQ 的专栏上发布，这篇就做个开始吧。也欢迎大家找笔者合作，笔者从来灵活第一，不执一边，能把咨询做成培训，也能把培训做成咨询，反正目标都一样，是帮助有意愿的人把架构方法落地用起来。