84人学习
好书推荐
今天我们为大家推荐的是《企业级业务架构设计——方法论与实践》。本书作者是有着20年银行工作经验的资深业务架构师付晓岩。
此前我们曾经推荐过付老师的一本书叫《银行数字化转型》，当时我们就提到，在付老师20年的工作经验当中，有12年业务领域经验和8年IT领域经验。这点很重要，因为《企业级业务架构设计》的目标就是要在业务与IT领域架设一座桥梁，或者说，建立一套标准的语言体系，让业务与IT深度融合，从而设计出有效满足客户需求的企业级软件。
这本书适合谁读呢？
首先，企业管理者，管理者决定着企业的发展方向，但现在很多企业并非不善于设计“战略”，也并非不精通“业务”，而是不熟悉“架构“。所以，管理者读此书，可以更好地带领企业获得架构能力，自上而下地建立业务架构。
其次，实施管理者，比如项目总监，各级项目经理、业务经理，技术经理等，他们可以在本书中获得企业级项目工作的方法论，并思考这些方法论与自身行业的适配性。
再次，技术人员，很多技术人员对自己到底是在实现“业务人员”的要求，还是在实现“业务”的要求产生过困惑。本书可以帮你解决这种困惑。
第四，业务人员，业务人员，业务人员在业务与技术融合过程中会更“痛苦”一些，本书会告诉你，如果业务人员能够将自己的思维“结构化”一些，这种痛苦会减少，让业务人员与软件的交互度更高。
第五，希望成为业务架构师的读者。本书虽然不能帮你学习更多垂直领域的技术知识，但却可能是你成为业务架构师必读的一本书。
好的，下面我们从五个部分来介绍本书的内容。
第一部分，业务架构基础篇：包括业务架构的发展历程；业务架构的作用，它和IT架构的关系；和架构伴侣：业务模型；
第二部分，如何设计一个企业级的业务架构；
第三部分，如何落地企业级业务架构方案；
第四部分，架构方法如何进行改良；
第五部分，业务架构与中台。
【第一部分】
第一章：业务架构的发展历程：
1987年Zachman提出的企业架构模型描述了一个企业的架构（Enterprise Architecture）。该模型按照“5W1H”，即What（数据）、Where（网络）、Who（角色）、When（时间）、Why（动机）、How（功能）6个维度，结合目标范围、业务名、信息系统模型、技术模型、详细展现、功能系统这6个层次，将企业架构分为36个组成部分，描述了一个完整企业架构所需要考虑的内容。
接下来，1995年，TOGAF架构将企业架构进一步定义为两个部分：业务架构和IT架构，这是业界首次明确提出了业务架构的概念，企业架构概念演化出业务架构概念。TOGAF指出，业务架构是将企业的业务战略转化为日常运作的渠道。
TOGAF之后，业界又先后诞生了FEA（联邦企业架构）和DODAF（美国国防部体系架构框架），前者着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，后者结构比较复杂，以作战为目标，但对企业级业务架构也有参考意义。
值得一提的是，付晓岩在本书的附录中有一篇关于马汉的《海军战略》一书的读后感，题目叫《位置、力量、资源》，这不禁让人在“商场如战场”的背景下思考，企业级业务架构设计为何可以从战争理论中获得启发？
以上是本书第一章内容，接下来我们来介绍第二章：业务架构的作用及其与IT架构的关系。
先说作用，简单讲，企业级业务架构一是起到传导作用，也就是把业务需求传导给IT；二是让企业战略落地，最终让企业成为高效的“数字化企业”。
事实上，很多传统行业中的企业已经实现了数字化，比如你认为是卖咖啡的星巴克，比如你认为是租车的滴滴，还有送外卖的美团，其实都已经是科技公司。这些公司面对所在行业的后知后觉者的时候，已经具备了“降维打击”能力。
那后觉者怎么办？是简单重复先行者的“套路”吗？还是高薪聘请技术人员？购买大厂的科技产品？在作者看来，这些都有必要，但是这些就好比你有一把狙击枪，但不代表你就是好的狙击手。所以要进行内在能力转变，这种能力就是企业级业务架构设计能力。
说完了业务架构的作用，再说它与IT架构的关系。作者认为，业务架构应当是企业战略而非IT战略的一部分，作者用一张图说明了两者的关系。用个比喻的方法说，业务架构是“灵魂”，而IT架构则是“容器”。而这个“容器”又如何分类呢？作者认为可以分为：应用架构、技术架构、数据架构、安全架构。在这一部分，作者还介绍了这四种架构的特点，及其相互关系。
以上是本书的第二章内容，下面介绍第三章：
第三章，付晓岩老师从“模型”的概念入手进行论述。其实我们所说的模型，可以是具象的，比如售楼处的楼盘等，也可以是抽象的，比如软件开发中常用的时序图、状态图等。简单讲，模型就是一种表达形式。人类语言也可以视为一种模型，是头脑中想法的表达，而业务模型，就是对业务的表达。
那业务模型究竟要表达什么呢？最主要的就是组织及其运作过程。比如，一切盈利企业基本行为都可以用一个顶点为“成本、收入、利润”构成的三角形表示，而企业行为就可以根据这个三角形进行分析。
有了这个基本概念，作者介绍了常见的建模方法，比如表现为垂直职能带型流程图的ISO9000模型，比如致力于为所有业务用户提供易于理解的符号的BPMN模型，又比如非专利的第三代建模和规约语言UML（统一建模语言）等等。
在本书当中，“业务架构是战略、流程、组织等业务元素的结构化表达”这一理念在书中反复出现。而业务模型则是这种结构化表达不可或缺的工具。因此，付晓岩在第三章介绍了建模原则与建模思维的应用。
建模原则之一是整体性原则，比如，几个小组在没有整体要求，也不允许沟通的情况下，设计出来的飞机组件，可能根本无法拼接到一起，所以一定要注重整体性；建模原则之二是合适性原则，生搬硬套的建模可能导致设计结果的“无用”，所以一定要将模型中各个部分、各类元素有机结合。
业务模型技能在项目完结之后还有用吗？作者认为模型思维会“终身受用”，比如它能让你更好地把握整体、穿透现象、保证落地。
以上是本书第一部分，也就是基础篇的内容，包含了本书的前三章。总结一下，第一部分作者主要介绍了业务架构的历程、作用，与IT机构的关系以及业务模型的介绍。
【第二部分】
第二部分，作者开始教我们如何设计业务架构。这一部分共分为4个章节，分别是业务架构设计的起点、过程、难点，以及一个虚拟案例，某商业银行业务架构的设计。
作者指出，设计过程是从战略分析出发，通过梳理目标，发掘能力需求，再通过价值链分析方式，构建企业整体能力布局。而业务架构设计与IT落地则是交替上升的过程。这个思路贯穿在第二部分当中。下面我们就来介绍第二部分的四章内容。
第四章，业务架构设计的起点，就是企业战略分析。战略分析可以用BMGovernance公司设计的企业战略设计模型作为辅助工具。作者详细介绍了如何用此模型进行企业战略分析。如果我们把这个像屋子一样的模型，和第三章提到的三角形的企业架构模型对比，可以把三角形理解为“大道至简”，而这个“屋子”则是“衍化致繁”。通过战略的建模，读者可以实践对战略的一次简易的“沙盘推演”，可以避免工作的盲目性。
企业战略分析的第二个方面是对标分析。作者指出，很多人将对标分析的好处定位于快速学习领先实践，但这种想法有两个误区：第一，很多时候，领先实践并没有真的研究透，即便请咨询公司出手，也多是研究表象，难以充分了解机理。如果真的想学透，恐怕要把实践真正的参与者“本尊”引入企业才行。
对标分析的误区之二，是对自己了解不够清楚。“知人者智，自知者明”，所谓“明智”，是要先认清自己，再了解别人。
同时，组织结构对架构设计的影响也不容忽视，比如谈及组织结构对系统设计的作用，“康威定律”就告诉我们，任意一个软件都能反映出制作它的团队的组织结构。而作者认为将这个规律延伸到需求方也一样适用：需求方的组织结构不可避免地会影响到系统的组件结构。
以上是本书第四章内容，介绍了业务架构设计的起点。接下来，第五章，作者介绍了业务架构设计的过程。
在设计过程中，作者先引入了价值链分析方法，并介绍了迈克尔·波特1985年提出的价值链（Value Chain）的概念，作者指出，价值链主要描述的是企业价值创造的过程，而描述价值链，则需要对企业行为进行分析，分析的维度包括业务领域的划分和业务流程的分析。
如果价值链是横轴，业务领域就是竖轴，而贯穿横轴的业务流程可以遵循前文提到的BPMN语法标准进行，用VISIO设计工具进行设计。
作者提醒读者注意的是：业务领域和业务流程分析阶段完成的模型通常不够准确，因为虽然已经将能力需求落实到了“工作流”当中，但还没有经过“精炼”。
接下来作者介绍了数据分析的方法，重点讲解了企业级数据模型。付晓岩用ER（实体关系）图展开，以金融类企业常用的FSDM（Financial Services Data Model）作为总体结构建立分析框架，将数据实体、数据属性进行归类，形成统一的企业级逻辑模型，并在生产阶段进行严格管理。
数据模型与流程模型是“难兄难弟”，第五章第四小节作者介绍了流程模型的表达方法，在第五小节作者总结了业务架构设计5个关键元素，也就是价值链、业务领域、业务流程、业务数据和业务组件，以及他们之间的逻辑关系。
在第六章，作者介绍了业务架构设计的难点，比如基本的标准化方法和如何避免过度整合。第七章，则以商业银行的业务架构设计为虚拟案例，帮助大家理解业务架构设计的过程。
至此，我们介绍了本书的前两部分，包括了第一章到第七章的内容。接下来是本书的第三部分，也就是业务架构的落地篇。作者用六个章节介绍了这个部分的内容。
【第三部分】
在第三部分的开篇之际，作者指出，落地部分并没有什么神秘之处，如果设计得当，落地更多需要的是决心和耐心。可见第二部分所讲的设计，乃是根本，设计得好，可以事半功倍。
下面我们介绍第三部分，第八章作者讲述了如何把一个业务架构模型转变成一个可执行的业务架构方案。因为业务模型所能表达的信息还是有限的，所以，要想落地成方案，并不能仅仅依赖之前所做的高阶架构，虽然这个架构有条有理，但还没有精细到可以直接出IT设计方案的程度，还需要继续向下分解为IT设计元素，继续在业务与IT间“搭桥”的过程。
对于方案的设计过程，作者认为方案要包含三个部分的文档：企业级业务架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述。作者用第八章一章的篇幅介绍了这三个部分文档的具体内容，同时也对开发团队规模较小的企业给出了具体的建议。
在业务架构方案做好之后，我们还需要做什么？付晓岩认为，不要指望IT设计可以自然产生，还需要业务架构人员去做充分的解释来保证架构方案的传导。如果架构设计人员缺位，业务部门和项目团队沟通的结果可能会和最初建模存在差异，久而久之积累出很多“地方语言”，业务架构只能“自说自话”。
因此，业务架构设计也必须努力打造“通用语言“，一方面培养合格的业务架构师队伍，作为业务模型的“嘴”，另外是加强项目外的宣讲，用业务模型去解释业务。让这个通用语言充分“用”起来。
第九章，作者介绍了基于业务架构方案的实施过程。作者结合第七章列举的虚拟案例，介绍了企业级业务架构进行IT设计的大致过程：1、细化业务架构模型；2、处理“新发现”；3、进行惯常的IT设计，但要建立一体化视图；4、业务架构的桥梁作用。
同时，作者还指出，业务架构是一个迭代的过程，会不断地进行反复和调整，并给出了处理这种调整的原则，比如为什么不能允许简单地指定架构？什么样的架构调整是可以接受的？什么样的不该接受？
以最后一个问题“什么样的架构调整不该接受“为例，作者指出明显违反既有规则的调整、不必要的重复造轮子都是不该接受的。
