作者：付晓岩
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
企业级业务架构设计：方法论与实践试读：
推荐语
前言 为何写作本书
第一部分 业务架构基础篇第1章 业务架构的发展历程1.1 Zachman模型1.2 TOGAF1.3 FEA和DODAF1.4 沉吟至今1.5 业务架构的定义第2章 业务架构的作用及与IT架构的关系2.1 业务架构的作用2.2 业务架构与IT架构的关系第3章 架构伴侣：业务模型3.1 模型与业务模型3.2 常见的建模方法3.3 建模原则与模型思维的应用
第二部分 业务架构设计篇第4章 业务架构的设计起点4.1 企业战略分析4.2 对标分析4.3 组织结构的影响不容忽视第5章 业务架构的设计过程5.1 价值链分析5.2 行为分析：业务领域和业务流程5.3 数据分析：企业级数据模型5.4 组件分析：行为与数据的结合5.5 业务架构的整体逻辑关系第6章 业务架构的设计难点6.1 基本的标准化方法6.2 避免“过度整合”6.3 何以解忧，唯有“融合”第7章 虚拟案例：商业银行业务架构设计7.1 价值链设计7.2 存款领域的模型设计7.3 贷款领域的模型设计7.4 跨领域的标准化7.5 组件设计7.6 案例总结
第三部分 业务架构落地篇第8章 从业务架构模型到业务架构方案8.1 业务架构设计不是为了替代需求分析8.2 制作业务架构方案8.3 小团队的应对之道8.4 需要充分解释架构方案8.5 努力打造“通用语言”第9章 基于业务架构方案的实施过程9.1 基于业务架构的设计9.2 基于业务架构的协调9.3 处理架构调整的原则9.4 企业级物有所值吗？第10章 建立转型后的长期应用机制10.1 项目结束了该怎么办？10.2 促进深度融合的需求管理机制第11章 这个“笨重”的过程与敏捷沾边吗？11.1 传说中和现实中的双模开发11.2 与正宗的敏捷对比11.3 与非正宗的敏捷对比11.4 且行且珍惜第12章 企业级的“五难”12.1 捷径难寻12.2 文化难建12.3 预期难控12.4 权责难定12.5 长志难立第13章 实战：实现了快速设计的案例13.1 项目背景及需求13.2 设计思路和业务架构方案13.3 案例总结
第四部分 架构方法改良篇第14章 如何支持面向构件的设计14.1 “乐高积木”式的软件设计14.2 “颗粒度”问题14.3 构件模型的设计方式14.4 建立构件模型的虚拟案例14.5 构件模型的技术设计建议14.6 本章小结第15章 构建轻量级架构管理工具15.1 构件模型的抽象要素及逻辑关系15.2 轻量级架构管理工具的设计原理15.3 采集项目信息的价值15.4 轻量级架构管理工具的优缺点15.5 应用轻量级架构管理工具管理新需求第16章 基于构件模型谈谈传统企业的产品创新16.1 信息传导：打造信息传递高速公路16.2 信息分析：创造高维数据16.3 创新平台：扩展构件模型16.4 构件模型及其应用设想的不足
第五部分 业务架构与中台篇第17章 中台之上17.1 阿里中台简介17.2 企业文化的作用17.3 由业务架构方法可以推导出中台设计吗？
尾声 对实践的再次思考
附录A 位置、力量、资源
附录B 积木式创新谨以此书献给我的妻子李穹和我的家人。推荐语（排名不分先后）
对业务架构的准确认识和有效实践，在当前云计算和数字化转型的浪潮中更显重要。本书破除了业务架构设计“水中月，镜中花”的迷思。阅读本书时可以非常强烈地感受到作者毫无保留地将多年一线架构经验和感悟倾囊相授。
书中既有对业务架构设计的清晰准确、通俗易懂的理论介绍，同时又提供了大量“接地气”的案例剖析。更难能可贵的是，作者在书中向读者提出了许多值得深思的议题，给读者充裕的思考空间，这对于希望在这一领域探索精进的读者将提供极大的帮助。
毫无疑问，本书是业务架构设计领域的佳作，对企业的管理人员、架构师、技术和业务人员都极具参考价值。——陈耿 微软全球黑带技术专家，《开源容器云OpenShift》《深入浅出Serverless》作者
架构设计之道在于针对业务场景给出优雅的解决方案，为企业降本增效。学习架构设计的过程是把静态的技术知识加以排列组合，形成动态架构设计思维能力的过程。本书除了系统性讲述业务架构设计知识外，还总结了基于大规模企业级项目研发的业务架构设计方法论。学习这些架构设计思维模型能够彻底掌握架构设计的哲学本质，为未来奠基。作者在架构设计方面造诣深厚，对技术细节的把握非常到位，特推荐之。——孙玄 转转公司首席架构师/技术委员会主席，前58集团技术委员会主席
二十多年前，我在BNR工作时发现了一个重要角色：系统工程师，也就是现在的业务架构师。面对企业级应用开发，业务架构师往往是不可或缺的。然而，业内对业务架构的论述很少，本书几乎填补了这一空白。
书中指出，业务架构是战略、流程、组织等业务元素的结构化表达。其是以实现企业战略为目标，降低系统复杂度，是构建企业整体结构化业务能力的分析方法，也是技术架构的灵魂。不同于需求分析或产品设计，业务架构的首要责任在于实现业务与技术的深度融合，打造能够让企业整体、尤其是业务与技术之间进行的有效沟通。
感谢作者，完善了我们对系统架构的视角和实现方式，感谢华章，让自己先睹为快！——曹洪伟 百度DuerOS首席布道师
我的职业生涯，有整整十年是从事企业级应用的架构设计和开发，其中大部分时间是在银行业和航空制造工业这两个信息化程度最高同时也是业务最复杂的行业。我深刻体会到在大型企业的复杂业务体系中，能充分描绘企业现状及企业战略，并使其具象化的业务架构对企业信息化建设的巨大推动作用。
而做好业务架构又是十分不容易的事情，它要求业务架构人员能深刻洞察企业业务及战略，并能通过特定的方法对业务领域、业务流程、组织架构、数据等进行行之有效的建模和表征。本书是作者多年企业级业务架构的经验及心得总结，既有由浅入深的理论讲解，又有贴合实际的案例实践，相信不同层次的读者都会受益匪浅。——李鑫 天弘基金（余额宝）移动平台技术总监兼首席架构师
市面上关于架构的书大部分都偏技术，但很多人忽视了技术永远是为业务服务的，所有的架构都是为了解决某种业务而诞生的。学习业务架构方法，才能真正学习到顶尖架构的精髓。希望读者通过阅读此书，可以初步领略到业务架构的魅力，并有所得。——龚健 资深架构师，美云智数PaaS产品总监
架构到底是什么？每个人都会有一些自己的见解，但是很少有人能够说得透彻，尤其是当我们沉浸在某一个特定领域的时候，该使用什么样的方法和思路去进行领域拆解、概念抽象以及细节忽视？本书所讲的一些方法原理和落地实践经验，对指导架构设计有非常实用的参考价值，从企业战略分析到与IT架构的衔接，从业务模型的打造到架构的管理方法，让我有一种茅塞顿开的感觉。相信从事架构设计、产品设计，甚至是开发人员都能够从本书中得到启发，不管是宏观还是细节，都能够帮助我们提高“内功”，我很乐意向架构师或者志在成为架构师的读者们推荐这本书。——王天庆 马蜂窝基础平台架构师
我最早知道付晓岩先生是看到他在InfoQ中文站上发表的连载文章，其中《中台之上》系列文章的第一篇就给我留下了深刻的印象，尤其是文章标题可以说是一针见血，作者从一开始就非常重视业务架构，提出了不要让“业务的归业务、技术的归技术”，表达了业务架构是连接企业战略和技术实现之间的桥梁这一重要观点。
谈到业务架构，其实很多人都会感到既熟悉又陌生，业务架构和我们平时经常接触到的软件或者系统架构有着本质的不同。业务架构是战略、流程、组织等业务元素的结构化表达，是凌驾于技术架构之上的需求原动力，可以说业务架构是商业价值交付的灵魂，从这个层面上看，业务架构的重要性不言而喻。比较可惜的是目前市面上基本没有系统性讨论业务架构以及相关设计方法和实践的书籍，而付晓岩先生这本书的出现必将填补这一空缺，作者以金融行业的业务架构作为实例，从“行线”和“知线”两个维度系统讲解了企业级业务架构的方方面面，是企业管理者，业务以及技术人员深入了解该领域的最佳途径。——茹炳晟 Dell EMC中国研发集团资深架构师
终于有了一本我渴望阅读和学习的架构书籍！
坊间有关技术架构的书籍实在太多了。技术当然重要，但如果技术的实现不是为了支撑业务，那么我们该如何真正有效地满足客户需求去设计与开发企业级软件呢？我在推动领域驱动设计时，越来越认识到打破业务与技术人员壁垒的重要性，但很多IT企业的管理者仍然没有充分地认识到这一点。要打破这种壁垒，靠自下而上的革命是不够的，需要管理者从企业战略的角度认识到业务对于软件开发的重要性；同时，还需要提供一套可以实施和落地的方法论——即本书重点讲解的业务架构。付晓岩老师结合自己在金融业摸爬滚打多年的架构经验，提出了业务架构的“知行合一”观点，完美地穿起了业务架构从理论到实践并行不悖的实施过程，使得本书知识不空洞、不浮夸，将相对抽象的业务架构讲得深入浅出，让读者充分认识到了业务架构师的重要性，以及该如何正确地打造企业的业务架构的方法。可以说，本书很好地填补了国内架构书籍因为重技术轻业务而产生的知识空白。——张逸 领域驱动设计布道师，《领域驱动战略与战术设计实践》课程作者
业务架构和基础架构有很大不同，基础架构相对更容易抽象，从而更容易理解事物的本质。业务架构需要解决各种形态的业务问题，需要的是具备较强的业务背景和技术背景的复合人才，是实现企业数字化转型的关键之一。以我从事十多年软件研发的经历来看，我们在构建业务架构过程中，往往是摸着石头过河，缺乏理论性和系统性的支撑。本书正好弥补了这方面的空白，作者以“行线”和“知线”这两条并行的主线为指引，全面介绍了业务架构的设计、落地以及架构的持续改良和中台建设等内容，为广大有志于成为架构师的技术人员和业务人员指引了方向。——郑然 百度主任研发架构师
国内很多企业在过去十到二十年间依赖人口红利实现了快速增长，随着人口红利的消退，传统企业都在谋求转型，期望实现效率提升、产品创新和模式创新。然而，转型的道路曲折而艰难，需要不断摸索，靠老板拍脑袋解决不了这些问题，必须以数字化为基础，通过打通IT系统实现组织协同，从而提高效率；通过构建业务中台，打造腰部力量，促进产品模式创新，通过构建数据中台实现科学决策。这一切都要以业务为核心，通过业务促进IT系统的建设。
本书作者根据自己多年的数字化转型经验，分享了业务架构设计的原理和落地方法，并由此阐述了如何通过业务架构推动技术架构的建设和中台体系的构建，是一本结合了理论、实践、热点的集大成作。
对于处于数字化转型各个阶段企业的CIO、技术VP、技术总监、架构师们，本书可以帮助他们在前期进行理论储备，起步期进行业务架构建设思路的建立，执行期提供实践案例参考，成熟期提供架构改良建议。在这里我强烈推荐本书，希望能够对传统企业数字化转型尽一份力。——刘超 网易杭州研究院云计算技术部首席架构师
当前，越来越多的传统企业正处于数字化转型的浪潮之中，以期提升产品研发及服务效率，在激烈的市场竞争中获得发展。而数字化转型非常重要的一步就是“业务数字化”，完善企业信息化及数据化的建设。
激烈的竞争环境及多变的业务架构，对企业级业务系统的开发造成很大的挑战。如何适应业务的多变性，开发出满足需求、可靠健壮、易于扩展的企业级业务架构，是非常有挑战的一件事情。它需要既精通IT前沿技术，又精通业务架构的复合型架构师人才。付晓岩先生正是这方面的专家，本书既包含了业务架构设计的一般方法论，又有当前最新的架构方法，还结合了作者多年的实践经验，给大家完整地呈现了企业级业务架构的全景图。——周健 招银云创金融基础云负责人
数字化转型是目前最热的话题，也是不同行业和领域企业转型的共同课题。企业转型相关的书籍不少，往往都集中在方法论的讨论上，较少分享企业转型的具体落地经验和实施改良方法。付老师这本书，把他在金融领域近二十年的经验和思考娓娓道来，从业务架构发展历程出发，以具体案例的形式，深入浅出地讨论了新业务架构的设计过程及难点，并着重探讨了落地实施的具体方案及相应的长效机制，逻辑清晰完整，案例引人思考，正如他自己所期望的，这本书可以让各类读者都能读得透读得懂。——黄帅 AWS认证云架构师“任何脱离业务的架构设计都是耍流氓”，这是我在“架构师之路”文章中提得最多的一句话。然而，我的大部分文章，不管是高可用、高并发、可扩展、微服务等，都是以写系统架构设计方法论为主的。如果想要了解业务架构方法论与实践，付老师的这本书是我阅读过的为数不多的既有体系化方法论，又有最佳实践的好书。
本书从设计起点，到设计过程、设计难点，再到落地实践、架构改良，系统且全面。同时又以银行业务为例，示范了一个典型业务系统的模型设计、标准化、组件设计与落地，让架构师更容易理解方法论如何落地。——沈剑 到家集团技术中心负责人 & 快狗打车CTO
对于应用系统而言，技术架构和业务架构都必不可少，擅长技术架构的人很多，但是能做好业务架构的人却极少。本书从“知行合一”的角度讲解了企业级业务架构设计的方法论和工程实践，是作者近二十年金融行业工作经验的总结，希望能对大家有帮助。——梁李印 滴滴大数据架构部高级专家工程师前言 为何写作本书
社会早已步入“信息时代”，以A（人工智能）、B（区块链）、C（云计算）、D（大数据）等技术为代表的科技应用正逐渐改变社会与生活，而在数字化浪潮中，很多企业仍处在艰难的转型甚至是转型前的阶段。
企业是否一定要转型呢？有的人说，一些企业没转型，现在也运转得挺好。这个现象有点类似于人类社会，人类社会的发展是不均衡的，既有步入信息社会的发达地区，也有原始朴素、低生产水平的欠发达地区，那这些“欠发达”地区是否需要“转型”呢？这并非是一个要与不要的问题，如果这些地区想要保持原有状态，那么，减少与外界的接触可能是不得不采取的措施，因为接触会带来融合，融合会带来改变。
对于企业而言也是如此，企业无法脱离其生存环境，如果环境发生了改变，那么企业也不得不跟着改变，因为企业是不能靠与外界隔离来生存的。企业转型是必然的，无非是要考虑转型的时机等。在信息时代，转型的方向自然是信息化、数字化，实现业务与技术的深度融合，讨论这类内容的书籍并不少，但是，实践效果却难以让人满意，“众里寻他千百度”，依然不见“灯火阑珊处”。
企业级转型是一个很艰难的过程，它并非一个单纯的技术问题，因为转型涉及企业的方方面面，如果想走通这条路，尤其是对传统企业而言，充分认识自身、寻找适合自身的方法极为重要。笔者多年从事企业级业务架构设计与管控工作，有幸参与了一次历久弥新的企业转型工程，对业务架构在企业级项目和企业转型过程中发挥的作用深有体会，因此，笔者将对业务架构工作的感悟与自身的学习结合起来，超脱原有的工作实践和理论指导，面向可操作的一般方法论写作本书。
本书在写作过程中受个人经验局限，仍多以金融业务为讲解对象，但是其方法在读者自行学习后，可以引入到其他行业的实践中，而非局限于金融业，这一点在笔者运营的公众号（晓谈岩说）的读者交流中得到了证实。纵然如此，本书终归是一家之言的分享，期待能为各位读者带来些许思考和灵感，以共同促进业务架构、企业转型方面理论与实践的发展。本书的主要特色
本书希望能够成为一本让各类读者都可以读得懂的架构书，因此，书中没有让人拿捏不准的概念。殊少概念可能会因为追求易懂的效果而让部分读者觉得有失严谨，但是，“易懂”也是架构设计应当追求的目标之一。与概念较少相对应，本书的“感受”成分稍多，因为笔者相信融入“感受”比单纯写方法更容易引起读者的共鸣与思考。本书的主要内容
完整的企业级业务架构实践应当包含两条并行展开的主线，一条为“行线”，一条为“知线”，如图1所示。“行线”是读者在日常工作中通常会比较关注的，其覆盖了企业级业务架构设计、实现及后期管理的完整过程；而“知线”则常常容易被忽视，尤其是在架构师或其团队之外。架构师有责任和义务持续改进、宣传架构设计方法，推动架构理念在企业以及社会范围内的磨砺、传播，实现架构工作的“知行合一”。出于这种认知，本书在内容方面设计了5个部分，其中，基础篇、设计篇、落地篇介绍了“行线”；改良篇、业务架构与中台篇探讨了“知线”，具体内容如下。图1 业务架构的“知行合一”
业务架构基础篇（第1~3章）分别介绍了业务架构的发展历程、作用、与IT架构的关系及业务模型的相关知识。
业务架构设计篇（第4~7章）分别介绍了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。
业务架构落地篇（第8~13章）分别介绍了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，并比较了与敏捷开发的异同，集中讨论了企业级项目的实施难度，最后，以一个设计实例展示了业务架构设计对提升企业开发效率的作用。
上述三部分完整介绍了业务架构设计的一般实现方法，并将企业级项目需要注意的问题及痛点融合在论述过程中，以供需要开展相关工作的读者参考。
架构方法改良篇（第14~16章）介绍了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对前文方法的改良设想，需要读者对此多加思索，切勿生搬硬套。
业务架构与中台篇（第17章）是对业务架构设计方法与当前热点——“中台”模式的一个比对。“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
附录部分收录了笔者做业务架构设计期间撰写的两篇读后感，希望对读者了解业务架构设计的作用、扩展设计思路有一定的帮助。如何阅读本书
本书适用于如下几类读者群体。
·企业管理者
管理者决定着企业的发展方向，以下内容都适合其阅读：本书第一部分中对业务架构发展历程和业务架构作用的探讨；第二部分中对企业战略的分析，对标问题的分析和组织问题的阐述；第三部分中对企业级项目实施、实施后管理和企业级难点的集中论述。实施问题虽然涉及项目中一些琐碎的工作，但是这些琐碎工作对项目的成败却有较大的影响，需要管理者在推动转型之前就有充分的认知。目前，很多企业在转型方面遭遇困难，这些企业并非不善于设计“战略”，也并非不精通“业务”，而是不熟悉“架构”，不清楚如何将战略通过架构落实到业务和技术实现中，企业需要具备“架构”能力，而这种能力应该由管理者带头，从业务架构能力开始，自上而下地建立起来。
·实施管理者
实施管理者通常为项目总监、各级项目经理、业务经理、技术经理等在项目实施过程中担任具体管理工作的人员。本书的前三部分对企业级业务架构设计及落地的阐述有助于实施管理者将本书的方法论引入其企业级项目工作中。第五部分的对比分析，也有助于各位实施管理者认真思考，寻找适合自身的方法论。第四部分则需要各位深入思考其方法与自身行业的适配性。
·技术人员
在实现业务与技术的融合方面，技术人员自然是需要向业务侧多迈出一步。相信很多技术人员对自己到底是在实现“业务人员”的要求，还是在实现“业务”的要求产生过困惑。本书前三部分论述的方法有助于技术人员掌握一种可以与业务人员更好地进行沟通的方式，也能够在项目中，尤其是在企业级项目中，从“业务人员”的众多要求中抽离出“业务”的要求。后两部分则有助于促进技术人员对方法论的深入思考。
·业务人员
在实现业务与技术融合方面，业务人员可能会更“痛苦”一些。一般业务人员在进行技术知识方面的学习时往往会更关注垂直领域，比如AI、区块链、大数据等，属于以应用为导向，但是很多人却忽略了对软件构建过程的关注，正是这种忽略导致了在开发中出现大量“冲突”。本书作为业务架构设计方法论，技术门槛相对较低，有助于业务人员了解如何结构化自己的思维。通过对本书，尤其是前三部分的阅读，辅之对其他软件工程经典著作的一般了解，业务人员足以对软件的设计与实现有一个清晰的理解，使业务人员与软件的交互度更高。
·希望成为业务架构师的读者
业务架构师并非一定要技术出身，但是技术实力雄厚的人显然具有基础知识方面的优势。业务出身的业务架构师需要克服更多的技术障碍，本书虽然不能帮助你学习更多垂直领域的技术知识，但却有可能是你成为业务架构师必读的一本书。资源和勘误
由于笔者的水平有限，书中难免存在一些不准确的描述，恳请读者批评指正。如果读者有更多宝贵的意见，欢迎通过邮箱yfc@hz.com联系笔者，期待读者们的真挚反馈，以在探索业务架构的道路上互勉共进。本书部分资源可在笔者的微信公众号（晓谈岩说）上获得。致谢
非常感谢InfoQ中文站的编辑杜小芳女士，是她的积极支持促成了本书前身《中台之上》系列文章的连载，也感谢InfoQ中文站的郭蕾老师和Linda老师对笔者的长期支持。第一部分 业务架构基础篇
业务架构并非软件工程中新诞生的领域，但是提及的人却很少。这个偶尔走进读者视线的词汇，经常带着一种“花非花、雾非雾”的“朦胧感”，很多人对业务架构究竟在软件设计中发挥了什么作用、有什么好处，以及业务架构和应用架构的关系、业务架构师和产品经理的区别等基本问题说不清、道不明。《软件工程》《软件系统架构》《系统分析与设计》等大家耳熟能详的经典教材也很少提及业务架构这个概念，更不用说企业级业务架构了，目前市面上也几乎没有专门论述业务架构及其设计方法的书籍。本书作为一本企业级业务架构专述，将从业务架构的发展历程、基本理念讲起，让读者对业务架构有一个基本的了解。第1章 业务架构的发展历程
与软件的发展历史相比，业务架构的发展历程其实并不算短，而且也具有几个颇具影响力的架构设计理论。1.1 Zachman模型
业务架构这个词最初是隐藏在企业架构（Enterprise Architecture，EA）中的。企业架构是20世纪80年代的产物，其标志就是1987年Zachman提出的企业架构模型，该模型按照“5W1H”，即What（数据）、Where（网络）、Who（角色）、When（时间）、Why（动机）、How（功能）6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统这6个层次，将企业架构分成36个组成部分，描述了一个完整的企业架构需要考虑的内容，如表1-1所示。表1-1 Zachman模型简介
Zachman模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构的概念，自然也就没有包含构建方法，所以，Zachman模型应该算是业务架构的启蒙，同时，它也表明了这一工具或技术的最佳使用场景——面向复杂系统构建企业架构。1.2 TOGAF
1995年，大名鼎鼎的TOGAF登场了，这个在企业架构市场中占据了半壁江山的架构模型明确提出了业务架构的概念。TOGAF将企业定义为有着共同目标集合的组织的聚集。
例如，企业可能是政府部门、一个完整的公司、公司部门、单个处/科室，或者是通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF进一步定义企业架构分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。业务架构是将企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，其包括业务的运营模式、流程体系、组织结构、地域分布等内容。
TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF还提供了一个详细的架构工件模型，如表1-2所示。
从表1-2中可以明确看到业务架构阶段的交付物，这些内容也清楚地说明了业务架构在软件工程中的位置。相信很多对架构有兴趣的读者都认真学习过TOGAF模型，此处不再赘述。表1-2 TOGAF9交付物：目录、矩阵、图1.3 FEA和DODAF
在TOGAF之后，又先后诞生了FEA（联邦企业架构）和DODAF（美国国防部体系架构框架）。前者的体系由5个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）和技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，相当具有“企业级”理念；虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。后者体系比较复杂，共有8个视点52个模型，但是实用性不错，据说美国国防部和一些相关企业都在使用，详细内容如表1-3所示。
表1-3中的能力视点和作战视点就是我们做企业架构时通常关注的业务部分。这两个模型在网上都有相关资料，感兴趣的读者可以自行查阅。1.4 沉吟至今
通过寻根溯源我们可以发现，即便是从TOGAF算起，业务架构这个词也有20多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。笔者曾就职的单位曾经实施了一个长达数年的、以企业级业务架构驱动的转型项目，但是很多企业并没有这样的经历，因此，每当与技术人员讨论至此，他们就会觉得业务架构有点儿虚，细究可能有如下几点原因。
1.用得少
原有的单体式或竖井式开发依然是企业更常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析即足以满足其开发需要。表1-3 DODAF的核心——8个视点与52个模型
2.难设计
业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难。业务架构对战略的分解、业务架构自身的整合与标准化，到IT设计的过渡都存在不少陷阱，业务越复杂宽泛就越难驾驭。因此，即便是尝试过业务架构设计的企业，也有不少是将业务架构设计保持在高阶状态，让做过的人自己都觉得有点儿没底气。
3.易偏离
施工期间由于客观因素可能会导致实施对业务架构的偏离，这种偏离如果没有得到及时纠正或架构调整，那么累积久了就会造成业务架构的失真。
4.难维护
少数度过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。1.5 业务架构的定义
业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构与其他架构一样，其目的也是要降低复杂度，从更好地规划和实现系统，因此TOGAF将业务架构归属于IT战略部分。但是从笔者的实践经验来看，业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变，所以，应当将业务架构从IT战略中独立出来，更多地面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构要想真正承担起这一职责，还需要改进、简化业务架构设计的方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，“熵增”一定会将已经建好的架构秩序回归到混沌状态。
说到这里，本书也尝试为业务架构提供一个简单的定义：以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。业务架构就其方法本身而言，既可以用于单个产品线或业务种类的领域级分析，也可以用于跨越产品线、业务领域的企业级分析；就价值而言，后一种显然对企业具有更高的价值，更值得企业去尝试、推广。因此，本书如无特殊说明，使用“业务架构”一词时多是指“企业级业务架构”。不同于一般基于业务诉求的需求分析或产品设计，业务架构的首要责任在于实现业务与技术的深度融合，在于打造能够让企业整体，尤其是业务与技术之间有效沟通的“通用语言”。
如今大热的“中台”概念，说到底也是一种业务架构设计结果，是对企业能力的一种规划，只不过阿里的实践代表的是自下而上的积累方式，而业务架构设计通常是自上而下的规划与演变。如果认真回顾软件设计的发展历程，那么你一定可以发现，所谓的“中台”绝非是一种超越了“企业架构”这个概念的存在。因此，若想要深入理解“中台”，那么多学习业务架构、软件架构的历史还是很有必要的。第2章 业务架构的作用及与IT架构的关系2.1 业务架构的作用
业务架构的作用通常被认为是连接业务与IT的纽带，用于实现业务需求到IT的顺利传导，对于TOGAF等企业架构理论来说，业务架构也承担着将企业战略落地的职责。任何方法其实都有一定的时代性，除了上述一般意义上的作用之外，在通向“数字化”时代的进程中，业务架构的独特性在于帮助企业完成了深刻的“数字化”转型，使企业通过信息技术将内部、业务与IT深刻地连接起来，成为高效的“数字化”企业。
1.传统行业中的先行者已经实现了“数字化”
有人说，未来的企业都是科技公司，虽然就目前来讲还为时尚早，但是，科技已经极大地改变了很多传统行业。读者都知道BATJ（百度、阿里巴巴、腾讯、京东）是科技公司，其实星巴克也可以算是科技公司了。美国的星巴克门店，将近16%的收入是来自于其手机客户端；星巴克自己的App有近1300万的活跃用户，星巴克内部已经将网页、手机、社交媒体、网络营销、StarbucksCard、电子商务、Wi-Fi、星巴克数字网络和新兴的店内消费技术等，统一作为数字业务战略。
近年颇受大众关注的滴滴，在2016年就已经实现日产生数据超过50TB（相当于5万部电影），每天规划90亿次路径；据称2017年全年累计提供出行服务74.3亿次。
美团也是人工智能的“玩家”，其开发了服务快递骑手的语音助手，支持骑手全程通过语音与系统进行沟通、确认，免除了手动操作，提高了效率和安全性。以派单操作为例，语音系统会提示：“派单，从哪里到哪里，收到回复”，骑手只需回复：“收到”，系统即可确认派单。到了目的地附近时，骑手亦可以通过语音关键词回复，直接拨打电话，从而省去了掏出手机这个动作。在电量过低的时候，系统会提醒骑手注意电量，骑行速度过快的时候也会提醒骑手放慢速度，到达顾客附近时还会自动提示顾客的地址。美团的语音助手不仅方便了快递骑手，也使得快递过程更加安全，减少了事故发生的几率。
倒回十几年前，恐怕没有多少人真的相信零售、餐饮、出租车、外卖这些行业会与科技如此紧密相关，甚至会直接成为科技企业，而他们所用的技术也已经是大多数普通业务人员无法理解的了。这不仅仅是指技术原理无法理解，就连应用方式也都无法理解了，这是一个真实的“数字鸿沟”，其赋予了先行者“降维打击”的能力。
2.后觉者如何启动自身的“数字化”
很多人都清楚地认识到了科技的力量，心里也明白要应对技术推动的跨界竞争，那么后觉者应该怎么做呢？是简单重复先行者的“套路”吗？或者是高薪聘请一些技术人员？还是购买大厂的科技产品？这些虽然都是很有必要的，但正如交给你一把狙击枪，不代表你已经成为一名合格的狙击手一样，你还需要内因的转变，这种转变才是最终促成自身数字化转型的关键。
转变当然不是让所有人都去跨领域学习IT技术，全去当“技术能手”，而是转变思维方式，架起一道跨越“数字鸿沟”的桥梁，这就是业务架构的核心作用。业务架构可以帮助业务人员整体化、结构化地思考问题，从业务和系统的整体视角，附带一些对技术的基础了解，如分层理念、服务化、微服务化等，去理解业务和技术；同时还能够帮助技术人员理解、归纳业务人员的想法和目标，从而让业务和技术能够处于同一个语境之下，使用同一种“语言”工作。业务架构能够让“后觉者”从认知自身开始完成一场深刻的“数字化”转型。
3.业务架构带动深度融合
曾经的业务不用管技术怎么实现、技术能听懂需求就足够的时代已经过去了，现在是深度融合的时代。深度融合代表互相深入理解，而这种理解首先需要从思维方式的转变开始，通过建立业务架构，业务和技术都能向对方的领域多迈出一步。当然，这一步对业务人员的挑战更大，但信息技术是这个时代的特征，在一个信息化的时代，就得具备这个时代的思维方式和基本技能，这是任何人都无法回避的问题，就如同从农业时代的战车到工业时代的坦克的变化一样，无论是其战术还是对操作者的技能要求，都发生了翻天覆地的变化。
在构建业务架构的过程中，业务人员需要技术人员的大力协助来共同掌握这个方法，这不仅是一个通向理解的过程，更是一个达成信任的过程。此外，我们无法忽视的一点是，如果业务本身不能被很好地结构化、模块化，那么技术人员也很难做出一个具有良好架构的系统，就算你是中台的“铁粉”，也无法解决这个问题。所以，培养业务人员的逻辑思维、架构意识，对于系统开发而言，只有好处，没有坏处，要努力让业务“懂”技术。
有些技术人员会觉得应该让业务人员只专注业务，但是不妨想一想，业务人员和技术人员在现实中的比例，你会发现，要是业务人员也能对技术的思维方式有所了解，那将会对技术的合理应用乃至创新产生多么大的推动力。打个不恰当的比方，技术人员就好比是茶商，你可能想象不到，有多少现代人的喝茶习惯、茶叶知识都是拜茶商所赐，客户对茶叶了解地越多兴趣就会越浓，就更愿意尝试不同的茶叶、茶具以及泡茶技法。很多消费者最终在知识、兴趣上都远超一般的茶商，这就是人们常说的培养客户，与客户共同成长的案例吧。
4.来自银行的声音
大型商业银行业务种类繁多、组织结构庞杂，每年的IT投入也是不菲的，他们更需要进行合理的“企业级”规划以实现IT对业务发展的支持，应对来自互联网企业的跨界竞争。
2017年6月25日，中国建设银行宣布，该行完成历时6年的“新一代”核心系统建设，明确称其采用了企业级建模方法，形成了以“四个一（一套模型、一套IT架构、一套实施工艺和一套管理流程）”为特征的企业级工程实施方法，全面建立集团层面的流程模型、数据模型、产品模型和用户体验模型；2019年4月，中国工商银行金融科技部总经理在《中国金融电脑》杂志上撰文称，“中国工商银行整合构建企业级业务架构”，“重构了适应新时期发展需要的业务架构视图，重新规划整合了28个领域的业务架构，形成了2300余个任务组件”，“通过强化业务架构的顶层设计和跨条线的协同联动，为后续进一步打造更具新时代基因的智慧金融体系奠定基础”。
这些银行的应用能够为企业级业务架构方法提供了更多的有效性佐证和实现上的借鉴。
关于业务架构作用的讨论，读者可以进一步阅读本书的附录A，该篇附录是笔者在进行企业级业务架构设计工作期间，阅读马汉的名著——《海军战略》的读后感，也是对业务架构作用的一种思考。2.2 业务架构与IT架构的关系
1.5节中提到过，TOGAF框架将业务架构视为IT战略的一部分，但事实上，业务架构应当是企业战略而非IT战略的一部分，它不同于通常意义上的业务需求，而是企业业务战略的实现方法。因此，业务架构范围是可以大于IT架构范围的，可以包含企业战略的非系统化部分，是企业业务的全景描述。IT架构则是用于企业信息化建设的，是企业战略的系统实现部分。二者之间的关系，用灵魂与容器来形容也许更为恰当。业务架构是灵魂，IT架构是容器，即灵魂的载体，没有灵魂，只有容器是没有生机的，所以，技术人员需要关注业务和业务架构。
业务架构与IT架构的关系可以用图2-1加以说明。图2-1 业务架构与IT架构的关系
业务架构可从企业战略出发，按照企业战略设计业务及业务过程，业务过程是需要业务能力支撑的，从战略到业务再到对业务能力的需要，就形成了支持企业战略实现的能力布局，可以将这个布局理解为业务架构，它是企业为客户创造价值的设计过程。业务架构设计会尽可能地追求以更为集约的能力实现更为多变的业务或服务，这其实也是中台战略追求的目标，因而，中台战略实际上也可以归结为一种业务架构设计。
业务架构设计完成后，“灵魂”就诞生了，IT架构则是根据“灵魂”的需要来设计“容器”。IT架构的分类方式并没有统一的说法，通常会分为应用架构和技术架构，而近些年随着大数据的发展，数据架构的地位直线上升。此外，随着数据安全问题日益受到重视，许多企业的IT架构也将安全架构置于重要的位置上。
IT架构的4种架构的特点以及关系具体如下。
1）应用架构重点关注的是功能布局，与业务架构的关系非常紧密，可以称其为业务架构设计的“紧后工序”。
2）技术架构主要关注分层结构，对于大型业务系统来说，一个逻辑分层很可能要通过多种平台才能实现，因此还会在分层中加入平台规划。技术架构与业务架构的关系不像应用架构那么直接，主要是通过对业务特征、业务量等多种因素综合考虑分层的合理性和平台选型，通常业务架构设计不会涉及这部分工作，但业务架构人员应当了解本企业的技术架构及特点。
3）数据架构中有一个重要的组成部分是数据模型，数据模型与业务架构关系密切，甚至可以归类为业务架构的组成部分。
4）安全架构与业务架构的关系一般不是十分紧密，但是目前安全架构设计的一个发展趋势便是在向业务架构靠拢，或者说是向企业战略靠近，以使得安全架构设计更贴近实际业务需要，符合企业发展方向，而不再局限于传统的网络安全、信息安全等防护型工作，需要体现出更多的“规划”特征。
从上面的介绍可以看出，作为“灵魂”的“容器”，IT架构中的应用架构和数据架构与业务架构的关系是最为紧密的。从实践的角度来说，如果企业没有那么多的架构设计人员，那么应用架构与业务架构可以合并，毕竟业务能力规划清楚之后，向部署延伸一点就是应用架构。如果将业务架构与应用架构合并，那么让经验丰富的技术人员担任此项工作会更为合理，但要求相关人员必须具有或者培养良好的业务思维。数据架构中的数据建模工作更是可以合并在业务架构设计过程中。
将“灵魂”注入“容器”是技术人员的重要工作，而能否顺利注入，让“灵魂”有个适宜的居所，则有赖于对“灵魂”的充分认知；而引导这一认知过程，让原本朦胧神秘、纷繁复杂的“灵魂”清晰可见的，正是业务架构。第3章 架构伴侣：业务模型
业务架构是战略、流程、组织等业务元素的结构化表达，因此，说起业务架构，自然离不开结构化表达的基本方式——业务模型，所以本章将重点介绍业务模型。3.1 模型与业务模型
业务模型也是模型的一种，因此我们需要先从模型讲起。关于模型的概念，各位读者可以查到很多种定义，不过，笔者觉得百度上有一种定义比较容易理解：模型是所研究的系统、过程、事物或概念的一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。
很多人一谈起模型就认为模型是抽象的，模型最重要的就是抽象，这种说法对软件开发人员而言并无不妥，但是对于理解模型的概念而言，还是有些狭隘了。模型也可以是具象的，可以是实物，比如售楼处常见的楼盘模型，古时的工匠为皇家修建故宫、亭台楼榭时，也会先做出精巧的木制模型，而且是与实物构造一模一样的“高精度”模型。模型不仅可以是真实的事物，也可以是虚拟的，只要想象力足够强大，即可创建虚拟模型，比如时下很流行的高达玩具模型、变形金刚等。模型当然也可以是抽象的，比如软件开发中常用的实体模型、时序图、状态图、用例图等。图3-1是几种不同类型的常见模型。图3-1 各种不同类型的模型
模型就是一种表达形式，其实我们所说的话也可以视为一种模型，它是我们头脑中某种想法的表达，表述的过程即可看作是建模的过程，同时我们的表述还遵循了一定的语法规则。所以，模型其实并不神秘，对于业务人员而言，工作时经常会画的业务流程图也是一种模型，与软件开发中所用的模型相比，无非是存在建模视角和抽象程度的差别。
理解了模型，我们再来看一下业务模型。套用上文所述的概念，业务模型就是对业务的表达，至于这个业务的范围就要看实际需要了。如果只是针对一个产品，那么业务模型可能就是对产品的设计、生产、销售、使用、售后管理过程的描述，其中还要包含所有参与方的目标、活动、角色、职责等。如果针对的是一个大型企业，那么业务模型的范围就可能包含多条产品线，每条产品线都有不同的业务过程，而所涉及的参与方也会更多、更复杂。
所以，业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形，如图3-2所示。图3-2 企业的业务模型
图3-2所示的这个三角形可以说是一切盈利性企业的基本行为，企业为生产而投入成本，产品或服务销售后获得收入，而衡量企业业绩的最基本方法就是计算收入减去成本所得的利润。
所有企业的行为都可以从这个三角形出发进行分析，比如，一个企业的基本流程可以概括如下。
企业确定向哪些人销售自己的产品或服务，这就体现了企业自身的价值定位。
·企业准备组织哪些人进行生产、销售，在什么样的渠道上销售，为此投入什么样的资源，这就是企业的生产和销售流程。
·收入和成本都需要记账，这就是财务会计的流程。
·对利润实现情况的衡量、盈亏原因的分析等，都体现在管理会计中。
所有的行为都会产生数据，这些数据是我们做系统设计时的必要输入，是结合业务流程做架构分析的基础。从这个最高阶的核心模型出发，我们可以演化出整个企业的业务过程，可以模型化地创造一个企业，这就是所谓的“大道至简，衍化致繁”。3.2 常见的建模方法
1.ISO 9000模型
业务人员在业务学习过程中很容易接触到流程模型，比如ISO 9000质量体系中会使用的流程模型。ISO 9000质量管理体系是国际标准化组织（ISO）制定的国际标准之一，是指由ISO/TC 176（国际标准化组织质量管理和质量保证技术委员会）制定的所有国际标准。该标准可以帮助组织实施并有效运行质量管理体系，是质量管理体系通用的要求和指南。
1992年，我国等同采用ISO 9000系列标准，形成GB/T 19000系列标准，随后，各行业也将ISO 9000系列标准转化为行业标准。申请ISO 9000质量认证的企业，通常要绘制企业的业务流程图，流程图的样式为垂直职能带型，通常使用Visio工具进行绘制，参见图3-3所示的样例。
ISO 9000模型对业务人员非常友好，但是，将其应用到软件设计领域，则会出现表达能力比较单一，对技术分析而言有所不足的问题。
2.BPMN模型
BPMN（Business Process Model and Notation）即业务流程建模与标注，是由BPMI（The Business Process Management Initiative）开发的一套建模标准语言。2004年5月，BPMI正式发布了BPMN 1.0规范，其后，BPMI并入到OMG组织，OMG于2011年推出BPMN 2.0标准，该标准对BPMN进行了重新定义。
BPMN的主要目标是为所有业务用户提供一些易于理解的符号，支持流程的创建、分析和实现，直到最终用户的管理和监控。开发BPMN的核心目标就是要构建从面向业务流程建模到面向IT执行语言的一座桥梁，因此BPMN的出现填补了从业务流程设计到流程开发的空白。
BPMN的工具较多，图元比较丰富，网上可以很容易地找到一些范例和工具介绍，如图3-4所示。
作为建模语言而言，BPMN的表达能力很强，其元素的核心集包括含事件、活动和网关在内的流对象（Flow Objects），含顺序流、消息流以及关联在内的连接对象（Connecting Objects），含数据对象、文字注释和组在内的人工信息（Artifacts），以及作为图形化容器的泳道。图3-3 ISO 9000模型示例图3-4 采用BPMN语法的流程模型示例
BPMN对于业务人员而言需要一定的学习过程，业务人员通过学习不难掌握BPMN，并且还可以将其应用到业务工作中；BPMN对技术端而言，除了可以正常辅助业务分析之外，还可以用于工作流引擎设计。
3.UML（统一建模语言）
技术人员非常熟悉UML（Unified Modeling Language，统一建模语言），UML是非专利的第三代建模和规约语言。UML可应用于一系列最佳工程实践，这些最佳实践在对大规模、复杂系统进行建模方面，特别是在软件架构层次中已经被验证有效。
UML体系中包含了3个主要的模型，具体说明如下。
1）功能模型：从用户的角度展示系统的功能，包括用例图。
2）对象模型：采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图。
3）动态模型：展现系统的内部行为，包括序列图、活动图、状态图。
由于UML在开发中已经广为使用，因此本书不再赘述其示例。UML对技术人员比较友好，但是其缺点也十分鲜明，就是对业务人员非常不友好。
业务架构的任务是搭建业务与技术之间的桥梁，所以作为业务架构在结构化表达方面不可或缺的工具，业务模型必须同时照顾业务与技术双方的感受，也即表达能力丰富、兼具业务和技术友好性的建模方法对业务架构而言更为合适。如果企业在以往的技术实现中已经习惯于采用某种建模方法，而犹豫是否要进行模型方法层面的大调整，则要考虑如下因素以判断是否进行该调整。
1）是否可以对原有方法进行改造以弥补缺陷。如果原来的方法太过面向技术端，那么能否增加面向业务端的合适的展现方式？如果对改造效果的评估或者试验不乐观，那么建议还是切换建模方法吧。
2）原有的模型成果是否还有复用的价值。如果企业决心进行大规模转型，那么原有的模型成果除了提供初期分析的信息输入之外，基本上再不会有多大的复用可能性，切换建模方法也就没什么不可以的了。3.3 建模原则与模型思维的应用
既然业务模型对业务架构、系统设计如此重要，那么建模是否存在什么“秘籍”呢？很遗憾，没有。这不仅是笔者个人的理解，不少关于建模的书中也都提到过，建模看似有很多种方法、标准可以遵循，但是模型质量尤其依赖建模者的经验，是一个“熟练工种”，经验丰富很重要。
虽然没有捷径，但还是有两个原则需要读者时刻注意。
第一，整体性原则。做模型切忌快速上手，不要轻易被业务细节吸引，更不要被立马解决问题的冲动所左右，一定要将问题域（或者说建模对象）通盘考虑清楚，先有整体轮廓再考虑局部设计。管理课上讲沟通时经常会列举一个“做飞机”的例子，先将听课的学员分成若干组，每个组设计飞机的不同部分，比如机首、机身、机翼、机尾，而不给出整体要求，组间也不允许沟通，然后将各组的设计拼接起来，最终很可能就会看到如图3-5所示的这种结果。图3-5 拼不上的“大飞机”
没有整体性原则做指导，就真的可能会做出不仅飞不起来，而且还极其“丑陋”的飞机。企业中常见到的“竖井式”开发，也会出现这样的情况，每个子系统独立工作时都很正常，协作起来就不行，因为原本就没有按照整体进行过设计。
第二，合适性原则。读者可能听过这样一个比方，将世界上最美的五官凑在一起，并不会成为世界上最美丽的脸，这就是合适性原则。美丽的脸通常是五官比例好、搭配好的脸（如图3-6所示），也就是说，模型中所包含的各个部分、各类元素要有机地结合在一起，而不能在设计时为了图新潮、赶时髦，甚至为了建模者个人的“执念”，放大需求、胡思乱想、生搬硬套，只想进行“理想”的实现，而不进行“合适”的实现，漠视客观现实和循序渐进而导致设计结果的“无用”。图3-6 合适的五官才是美丽的五官
业务模型是为业务架构服务的，所以细心的读者也一定注意到了，上文所述的这两条原则其实也是架构设计的重要原则。建模唯有不断练习，不断参与项目实践，以获得对建模成果的重要反馈，才能有所提高。设计上经常将不管实现结果的架构师称作“PPT架构师”，其实建模也是一样，若不能在生产环境中得到反馈，那么建模者也会成为“PPT模型师”，所以说，实践是理论之源。
做过建模的人都能理解，认真建模是一件枯燥又繁琐的事情，前文中也曾提到过，业务架构设计可以帮助业务人员提升逻辑思维能力，应该让业务人员多参加。那么对于广大业务人员而言，投入这么大的精力参与这么枯燥的工作，完结了项目之后，这技能还能用得上吗？答案是肯定的，虽然业务人员不会在项目结束之后还继续建模，但是重要的模型思维却是终身受用的。
笔者个人总结出的如下3点模型思维是在各类工作中都值得借鉴的。（1）把握整体
关于把握整体的重要性这里不再赘述，关于其应用场景，举例来说就是，对于领导交办的任何工作，尽可能不要第一时间就“Just do it”，而是要先抽出点时间，考虑下事情的来龙去脉、前因后果，这样才能控制好工作的度，以免过犹不及。时间和人力是企业最宝贵的资源，不是任何事情都值得投入最大的精力去追求满分效果，要从整体着眼来评价工作事项，尽量杜绝过度“敬业”对时间和人力的浪费。（2）穿透现象
露出水面的往往是冰山一角，能够透过现象看本质是对建模人员工作能力的基本要求。这种注意事物内在联系、本质差别的能力，有助于读者拨开笼罩在现象表面的“迷雾”，找到解决问题的最佳方案。这种思维方式在任何工作中都是可以用得上的。（3）保证落地
曾经有句流行语：“一切不为业务目的服务的技术都是耍流氓”，这里套用一下，“一切不考虑落地的架构设计都是耍流氓”。架构不能只是停留在口头上，纸面，真正了解架构本质的人，无论做出什么样的设计方案，都会以落地实施为前提。对应到日常工作中，就是无论何时何地，各位提出的工作建议都不能只是“空谈”，都要为其实现而负责。落地靠的是经验、方法、能力，而不完全是信心，所以，工作要慎重，胆大的同时更要心细。
关于模型的一些基础性介绍先到此为止，本书所讲的业务架构都是使用业务模型来构建的。虽然业务架构与模型之间关系紧密，但是必须明白的是，架构不等同于模型，模型也不等同于架构，不要将二者混为一谈，架构相当于思想，模型只是表达。实践中如果遇到问题，一定要先想清楚原因，不要因为模型表达方式不理想而认为架构无用，也不要因为架构设计不理想而埋怨模型。
目前主流的软件设计方法其实都是MDD（Model Driven Develo-pment，模型驱动开发）形态的，无非是建模工具、建模方法的差异，即使是火热的中台模式，其设计过程也离不开模型方法。第二部分 业务架构设计篇
在开始讲述业务架构设计之前，本篇首先介绍一下业务架构的一般实现过程，以便读者对此有个整体印象。
业务架构是面向企业战略和企业整体的，而非仅处理单一需求。其一般实现过程包括设计和落地两个不断交替上升的过程。其中，设计过程为从企业战略分析出发，通过梳理企业目标，发掘能力需求（既可能是企业自身业务与技术水平发展产生的主动能力需求，也可能是科技导致的业态变化、竞争压力产生的被动能力需求）；再通过价值链分析方式，构建企业整体能力布局（即业务架构），并在分析过程中，将能力需求放入能力布局中，并以此在业务层面落地战略、检验战略的可行性，甚至调整战略。
落地过程主要为通过业务架构驱动IT设计、协调实施过程，建立业务架构元素与IT设计元素之间的联系，并在实施中对业务架构进行基于实现的最终调整，以确保业务架构与IT实现之间的一致性。落地后则会依靠业务架构管理企业需求、处理战略迭代的业务，业务架构设计与IT落地交替上升，如图1所示。
试读结束[说明：试读内容隐藏了图片]