企业级业务架构设计：方法论与实践

纯阳书评第348期《企业级业务架构设计》生活中总有一些事不好做，也注定有一些书不好写，这本书就挺不好写。本书之所以不好写，就因为本书偏偏要写企业级业务架构和企业架构那些事。 企业架构心比天高，命比纸薄。一方面志向宏大，试图彻底理顺战略、业务、流程、制度和IT，让战略统摄业务和IT，让IT真正支撑战略和业务。表面上看起来这个思路没有任何问题，甚至还可以称得上相当高妙，然而往深里边走一层，我们就会发现这么做显然会把摊子铺得过大，企业架构是最终要落地到IT这个层面的，但是一杆子把企业战略、组织结构等复杂要素都划拉进来，事情的复杂度就大幅上升了。原来可能只是一个IT层面的问题，这么折腾以后有可能升级为一个战略问题，转变为一个组织问题。另一方面尽管工作复杂度升级了，但是其主要推动者并没有升级，既不是战略制定者，也不是业务管理者，还是IT管理者，显然后者是没有更多的能量足以搞定企业架构所带来的高难度问题的。所以企业架构自从出世以来就被人挂在半空中，得不到水土的滋养，长期营养不良，不能正常成长。所以就像要给一个发育不良的孩子拍一张美颜照相当考验摄影师一样，以企业架构为主题写一本书也是很考验作者勇气的。 但是作者就是在这个背景下，迎难而上，写出这本书，所以这本书要论看点的话，第一个看点就应当是作者的勇气和担当，很值得钦佩和学习。 第二个看点是作者对于企业业务架构的洞见和经验分享。 说实话，在当前的企业IT实践环境中，能从事或者参与EA实践的机会是很少的，很多人对于EA的认知和研究可能只能是停留在那几本经典的书籍和togaf等标准的参考文档上。而作者在建设银行参与企业级业务架构的设计和项目工作，所以才有机会把理论和落地实践结合起来，在获得实际经验和感悟以后再重新思考理论和框架，最终形成自己对于企业级业务架构的理解，因而作者的分享很有价值，具有较强的稀缺性。 第三个看点是作者在企业业务架构的语境下对中台的解读。 在作者看来，中台这个新概念火起来了，但是压根没有跳出EA的范畴。说实话，一方面我们必须称赞作者深刻的洞察力，中台确实是业务架构设计和规划的一个必然结果，这点丝毫没错。但是另一方面我们必须强调中台显然又没有落在企业架构那个半死不活的窠臼中。显然这一点就是中台高明的地方，它让自己从一出生就脚踏大地，深深扎根在泥土里，不断攫取生长的营养。如果说企业架构是设计学派，那么中台至少是设计学派加适应学派，是要讲究设计，但是更要讲究对实际问题的解决，对实际情况的适应。因为适应，所以能活下去，因为能活下去，所以才给设计创造了机会，设计也才能落地，也才能活下去。 总之，作者迎难而上，写了一本注定不好写的书，尽管有些读者抱怨写的内容略有单薄，有些地方不够细致，但是我们还是应该为作者点赞，毕竟物以稀为贵，人家这是近几年的独一份，作者肯写这本书，就很难得!

架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案，架构往往是对复杂形态的一种共性的体系抽象。而企业架构（EA），是指一个组织单元的业务、应用、数据及技术基础设施等之间的关系，包括基线的、目标的及过渡的动态关系描述。打个比方，EA类似于城市规划，具体系统建设类似于一幢大楼的建设。企业架构是一个涵盖业务和IT的全面的企业蓝图设计工具，它可以帮助企业的管理者了解企业的构成和运营，发现问题并不断地改进。 企业架构可以分为两大部分：业务架构和IT架构。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的业务组件和分布、业务流程、组织结构、绩效考核等内容。IT架构指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。数据架构有时被称为概念数据模型（Conceptual Data Model）、企业数据模型、信息模型等，是指定义企业的数据项以及它们的属性和关联关系。应用架构是一个全企业的单一视图，规划定义IT系统和它们之间的接口以及集成方式。技术架构（ETA）是IT架构中比较底层的架构，它定义如何建立一个IT运行环境来支持数据和应用架构，以保证业务的正常开展。技术架构包括包括集成平台、公共服务平台、基础平台和安全平台等，基础平台包括数据中心、灾备体系和安全机制等部分此外，企业架构的建立和管理需要建立架构治理机制，这也是IT治理的一部分。 这本书的作者应该在金融行业企业架构方面经验非常丰富，他在书里讲了很多专业的企业架构模型，比如togaf，bmgovernance模型，我们对于企业架构模型（或者说蓝图）有了一个大致的了解，我们也跟着案例学会一步一步梳理我们公司的企业架构模型。但是架构模型梳理和应用是一个长期的过程，需要专人负责，才能显示出价值。但这些模型本身对我们把握自己的企业业务发展也是非常有帮助的，让我们站在中央位置，有全局的视角，调动我们的资源和力量来推动业务快速成长。我在网上也找了一些金融机构的企业架构案例，感觉规模越大的企业越需要投入更多人力物力财力才能做好企业架构的工作。比如，通过中国银行的案例可以对于这个工作本身和投入有个概念性的了解。 2003年9月，中国银行决定全面启动IT蓝图建设，提出实现全行信息系统数据集中、系统转型的宏伟目标，该项目是国内乃至国际上最大的IT项目，系统规模大、涉及人员广、实施难度大，涉及中行20多万名员工、1万多个网点机构、上百个系统的整体替换。在这个过程中，中行坚持自力更生与开放引进相结合，大胆创新、探索出适合中行IT蓝图建设的路子，该成果获央行2011年科技发展奖。2011年10月28日，中国银行总行IT蓝图总行成功投产并顺利对外运行，至此，中国银行历时8年的IT蓝图建设完美收官。 IT蓝图建设项目第一步就是IT蓝图制定，中国银行与国际知名咨询公司合作，从应用架构、基础设施、信息安全和IT治理四个方面对IT蓝图进行了全面规划，提出了包括交付渠道、客户管理、产品管理、财务会计和决策支持五个维度的目标应用架构，明确了中国银行信息科技中长期战略目标和发展路径，确定了“两地三中心”的数据大集中模式和“以客户为中心”的核心银行系统建设思路。后面的实施都是按照这个蓝图来进行的。 

开源为架构和软件带来了新的成长方式，共享让思维发展得更快、普及得也更快。但是，软件架构本身却只是积累了大量的案例，依旧难以标准化、自动化，哪怕是同一个行业的企业，为这家开发的软件却不能简单移植到另一家，很多商用化了的系统软件也还是离不开各具独特个性的本地化改造过程。云计算带来的SaaS虽然让软件应用省去了许多部署过程，但是，依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此，业务架构也就更不需要再继续纠结了。 对业务架构进行设计可能很快，也可能很慢。快无非出于两种情况：一是架构师自身的技术已达到炉火纯青的境界，设计能力超强；二是原有业务模型本身就已经很清晰了，可以快速分析业务变化，形成架构设计。我们更应该追求的是第二种情况，这也意味着首次建模，尤其是首次建设企业级模型，不要过快，对模型设计方法、业务流程分析、标准化过程，都要认真细致对待，只有基本功扎实了，才能有后面的“敏捷”。 企业级转型不可能是轻轻松松就能完成的，不少企业只是将企业转型当成一个项目，而忽视了对自身的调整。一个普通士兵要想变成一个特种战士，不是因为给了他一身价值高昂的装备，而是经过了地狱般的训练。上至最高管理者，下至普通员工，若人的思维不发生转变，则不会带来企业的转变。 为了推动企业进行真正的数字化转型，业务架构设计人员永远不要忘记，业务架构最重要的职责不是传递需求，而是藉由自身的努力，推动业务和技术的深度融合，业务架构最重要的职责是起到桥梁连通的作用。如果不能实现这一目标，也就不能真正实现一个快速响应内外部变化的企业级业务系统。 无论设计概念有多火热，客观地讲，一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的，也不会执着甚至偏执于方法间的争论。没有哪种设计方式是完美无缺的，软件行业没有“银弹”，任何一种方法都需要长期坚持与灵活运用的结合，都需要通过长期的实践不断进行总结和改良。如果一个方法没有被坚持数年以上，那么它可能连入门都谈不上了。

2020037。 这是一本很不错的业务架构方面的书，特别是前面的三部分，读起来很受启发，感觉学到了很多不错的东西。但是从第四部分开始就有些混乱，也许是我的功底不够，总觉得有点碎、乱、空，读起来感觉没啥滋味，也就开始快速阅读了~ 作者主要论述的是业务架构的概念、设计、落地和优化，这是任何一个项目实施过程中所最难的点之一。相对而言，技术好学，但对业务的了解，需要很大的投入与付出深度的学习才能取得一定的成绩。作为项目实施方，很难真正的对领域知识有极为深刻的理解，这个必须是在日常工作中与业务为伴，深入应用业务才可以。具备较强技术背景和业务背景的复合人才永远会被需要的，因为达到这样的目标需要较长的时间来学习、来领悟、来积累，所以具备这样能力的人不会担心被淘汰，我倒觉得这是人到中年，应对中年危机的一个最大的凭借或者是资本。 读完全书，很大的一个感受是作者对于中台有一种迷之偏爱，各个章节里都会努力将论述内容与中台联系起来，也许是中台这个概念太火的原因？但是我总觉得中台没那么好用，也不是那么靠谱，貌似现在也只有阿里真的把中台用的很好吧？云化好像也有过公司把头部公司的云平台移植到自己公司，结果是问题多多~所以，中台不是银弹，云化也不是银弹。但理解业务，立足业务，以业务为心，技术为骨倒是我等实现不断发展、坚定不倒的银弹~

时隔2年再次读本书，感觉熟悉而又陌生。 2年前从生态的角度来看本书，总觉得生长模型是从下而上和从上而下是相互依衬相互扶持的关系。 在2024年的今天，在多次商业计划和战略摸爬之后，发现的业务架构与下端的关系反而是 竞争型生长。 一是，没有什么商业模式是你想好了才会出现的，都是生长打出来的，且依赖时事关系。就如疫情里面的疫苗，核酸延伸出来的安全码和对应的商业，以及被救活的社区营销。二是，战略眼光要大于业务架构，一如Togaf里面的架构愿景。很多时候，其他企业生长模式是参考，必须走出自己的商业路线是一套曲折且迂回的过程。因为无论是在中国还是国外，要抄袭可以很快。怎样保持持续的商业优势，谁都不敢保证。看看疫情之后的大卖场。 祝总提到的任何业务都是三角稳定的三个点，客户高满意度，企业运行高效，产品高利润。这个三角形不能同时存在，否则商业模式无法适应场景进化。他必须是在一个阶段，一个固定点牺牲让另外两个点生长，然后换一个固定点牺牲迎来另外两个点新一轮增长。螺旋模型暗合商业模式。 其实所有的成长我觉得都是一样的模式，包括战略-愿景-业务架构-业务组织以及背后的应用，技术甚至上升一级的企业文化或更大的社群文化。 方法论只是引路人，修行还得靠自己通悟。毕竟通过别人手中的地图（架构或商业模式），是走不出自己的路，也找不到心中的好望角，物欲横流坚守至诚之心。

马汉总结的基本原理之一是，“任何地方的战略价值都要取决于以下三个基本条件：位置、力量、资源”。 位置是战略价值的基础 马汉在书中反复引用拿破仑的名言，“战争就是处置位置”，并强调“中央位置”对于形成内线优势的关键作用： 只有控制了中央位置，才可俯瞰战场，占尽地利。其实我们今天的模型工作，恰好居于现实世界和物理世界的“中央”，一边是真实业务构成的现实和需求，一边是网络、软件和硬件构成的系统，作为连接二者的桥梁，业务模型是必经之路。 而且，在企业级建模这个高度，“中央”的位置更加明显。我们要从总体战略着眼，观察业务能力的分解实现。 从模型出发，我们能在最短的时间内到达业务的任何一点，这是“内线”的优势，也是我们在进行业务建模之前不曾出现的“位置”。 位置的价值不言而喻，但是具体评价一个位置的战略价值，还要了解其是否能以适当的方法被绕过。一旦开辟了新的航道，旧位置的战略价值势必会随之削弱，苏伊士运河、巴拿马运河的出现都创造了新的战略位置。 业务模型也存在同样的忧虑，从整体态势上来讲，业务团队、开发团队并没有居于“中央位置”，他们分散在各处，并且由于习惯等多种原因，有各种旧的路径可以尝试，走旧路的方便也常常胜过对走新路的担忧，这都会使得“中央位置”的战略价值有所降低。 因此，我们不但要从制度、验证等方面入手，控制出现范围外开发的情况，更要严格监督二期、三期施工的企业级方向。 只有保证施工的企业级方向正确，才能造就新的地貌。这种新的地貌将使“中央位置”的“内线”优势凸显出来，使业务团队、开发团队都了解到，通过业务模型才能更快捷地走到他们想要到达的地方，其他途径只是绕远，徒增混乱。 足够的力量发挥位置的作用 再好的位置，如果不善加利用，也无法形成价值，而利用位置，则必须要有力量。 在马汉的基本原理中，力量来自于舰队、要塞等军事单位，只有足够的力量才能充分发挥位置的作用。 但是，对于模型工作而言，这个力量是“软实力”，不能单纯依靠行政指导，而是要运用模型产生的效果，不仅要做到上文提到的“快捷”，更应注重运用模型分析问题、解决问题的能力，也就是模型对于业务架构的管理能力，近期对各种棘手业务问题的处理，已经显示出模型作为分析工具的价值。 我们不仅能够了解到目前的能力都分布在什么位置，更能够得知一项业务需求该去向何方，该怎样组合能力。解决问题，这是模型最大的力量，但是，这个力量的确需要在不断的使用过程中被人们逐渐认识、逐渐喜爱。 马汉在书中强调，力量的使用原则不外乎一点——“适度集中”，“处置位置”的目的也在于此。通过位置的选择，形成局部优势，这是最有把握取胜的方法，对于马汉而言，这甚至是舰船设计的指导原则。 从模型工作来看，将业务架构视作我们的最强力量，并将这一力量向需求前端延伸，从需求形成开始把控方向，使我们的力量作用在最柔软的点上，从而发挥更大的效力，也能使后端设计从源头上被我们导向理想的方向，这将使我们最终具有发挥位置优势所必需的力量。 资源是战略价值持久性的决定因素 “资源的丰富与贫乏的利与弊，尽人皆知”，马汉考察的是海权论，偏重于海洋的贸易价值。一个具有丰富资源的位置，将会具有更大的贸易潜力，会吸引更多的航线，位置的重要性会不断增强。 同时，资源也是战争的必需品。海军场站、前进基地的选择都会考虑据点周围的资源情况，这里所说的资源既包括自然资源，也包括外交等社会资源。考虑到模型工作的特殊性，即它是一种较为纯粹的智力活动，因而，人力是首要的资源因素。 根据我们对模型预期达到的高度以及对力量的期望，巩固团队核心，决定总体配系，是模型持久发挥影响力的基础。如果我们拥有充足的模型专家可以协助业务、IT处理各类棘手问题，那么整个团队的价值就会不断得到提升。 但是人力培养是一个漫长的过程，考虑到未来的长效机制，特别是后来才加入团队的人员，他们比起初期建模人员，将会更加缺少宝贵的实践机会，对于他们来说，“无论原理如何正确，都不过是根据客观的权威所做出的论述而已，而他们内在的信念和鉴别对于这些论述的正确性尚未予以证实，而只有内在的信念和鉴别才能在需要的时刻产生力量”，要想解决这个问题就要涉及了我们的第二项重要资源——模型资产。 业务模型由于其处在“中央位置”，从应用的角度，反映了业务结构；从组件的角度，反映了能力结构。 只有在这两个方向上保证准确性，我们才能不断获得前进的“阵地”。拿破仑说：“在战场上，最为巧妙的灵感往往不外乎回忆而已。”模型资产就是团队共同的“回忆”。 马汉在讨论关于战争原理的学习时，引述了查理大公的一句话： “巨大的成果只有经过巨大的努力方能获得”。

作为比建行更早做过企业级业务架构设计已经被拍在沙滩上的老银行人来说几句。对于企业级业务架构设计的方法论书中说的已经比较完备了，不再过多点评。要说一下自己的几个观点：一是业务发展太快。目前严格遵循企业级业务架构的逻辑已经不现实了。10年前这种模式没问题，大企业用于沉淀经验、培养人才、巩固优势。目前不适应，主要是这种模式太重，跟不上新业务的快速创新，你还没想好怎么统筹就已经过时了，特别是越来越多的跨界创新，还是DDD模型能更好的适应。二是不适应新的战略定位。战略是企业级业务架构的依据，战略本身的定位已经改变，企业级业务架构的前提不具备了，参考曾鸣教授“战略+实践”快速迭代的新战略模式，战略是动态调整的。三是不适应新的组织模式。企业级业务架构对组织变革要求太高，需要的是科层制的层层分解，未来的企业更多的是平台之上的敏捷组织，自下而上的模式更适合。四是不适应新技术。特别是大数据和人工智能的发展，技术驱动甚至颠覆业务的案例屡见不鲜，也是打破自上而下设计业务架构的关键力量。综上，个人建议中台模式这种自下而上总结、沉淀、升华的模式更适应未来的企业。绪先生个人评价，（欢迎关注公众号数据有情绪）

重读书籍，进一步认识了企业级业务架构的来龙去脉，我有几点体会： 1.业务建模与流程设计并没有那么神秘，和以前SOA那套思想的目标一样，都是为了化繁为简。只是更具体细化了业务和技术，然后通过分析对同一处理功能进行聚合处理，形成组件（与传统“组件”定义不一样）。 2.通用语言很重要，书中反复提到了多次，去年阅读时只是觉得为了减少项目成员之间的沟通成本，其实远远不止。从活动、任务到底层的实体和实体属性处理，都涉及边界问题，如果业务和技术人员理解不统一，影响面是层层关联的。 3.此书颠覆了以往的认知，打开了新世界，觉得对读者来说至少要有五年经验才能体会到。并且对领悟驱动设计、面向对象有一定理解，并能结合传统架构反复推敲思考。 4.从落地上来说，就和书中说的一样，需要企业有转型的决心，对全局业务和技术有足够经验的架构师，对企业现状有充分认识，以及足够的时间、人力和财力，才能够对业务和技术实现流程抽丝剥茧。

言之无物。更多像是夸夸其谈，也许作者以为自己理解了（说教很多），但实际没理解（实际案例很粗浅简略）。像什么呢？有点像“为赋新词强说愁”，以为能把“愁”相关的诗词背诵很多就懂“愁”了，但实际只懂皮毛，没有通过实践深刻体会过。

付晓岩老师的企业级业务架构设计一书，从架构基础，到架构设计，再到架构落地，架构扩展，架构和中台，层层递进，结合金融实例，谅解了企业转型中，业务架构的重要性和方法论，思想。业务架构是业务和技术的桥梁，bpmn设计可以画出业务范围和流程，包括企业定位，战略，组织。愿景，使命，目标为顶层，战略和战略能力是中层，战略又分客户关系，市场细分，形成收入；战略能力分资源，关键活动，合作伙伴，形成成本。二者融合，形成价值，价值可能产生利润。设计篇介绍了将企业业务放到模型层面，拆为价值链，业务领域，业务模型，业务行为，业务组件。划分清晰流程间的关系，各自模型的边界。落地篇先说难点，文化难建，权责难分，捷径难寻，预期难控，长志难立。业务架构师入驻业务线，形成融合基础，双模开发保证敏态和稳态更迭，特事特办。改良篇介绍了架构管理工具，产品目录形成的重要性，标签化的灵活性。最后介绍了和中台的关系，阿里中台是自下而上，长年累月沉淀的产物。企业业务架构更贴近业务一些。最后一点，合适企业的才是重要的，同时关注长期价值。