参考：
企业级业务架构设计：方法论与实践付晓岩（微信读书可试读前五章，已是精华）

业务架构是战略、流程、组织等业务元素的结构化表达。
业务架构人员的能力要求：能深刻洞察企业业务及战略，并能通过特定的方法对业务领域、业务流程、组织架构、数据等进行行之有效的建模和表征。

架构设计理论

Zachman模型

业务架构这个词最初是隐藏在企业架构（Enterprise Architecture，EA）中的。企业架构是20世纪80年代的产物，其标志就是1987年Zachman提出的企业架构模型，该模型按照“5W1H”，即What（数据）、Where（网络）、Who（角色）、When（时间）、Why（动机）、How（功能）6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统这6个层次，将企业架构分成36个组成部分，描述了一个完整的企业架构需要考虑的内容。

Zachman模型应该算是业务架构的启蒙，同时，它也表明了这一工具或技术的最佳使用场景——面向复杂系统构建企业架构。

TOGAF

1995年，大名鼎鼎的TOGAF登场了，这个在企业架构市场中占据了半壁江山的架构模型明确提出了业务架构的概念。TOGAF将企业定义为有着共同目标集合的组织的聚集。
业务架构是将企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，其包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF还提供了一个详细的架构工件模型：
TOGAF9交付物：目录、矩阵、图↓

FEA和DODAF

FEA（联邦企业架构）和DODAF（美国国防部体系架构框架）。
FEA的体系由5个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）和技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，相当具有“企业级”理念；虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。
DODAF体系比较复杂，共有8个视点52个模型，但是实用性不错，据说美国国防部和一些相关企业都在使用。

业务架构定义

定义：以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。
业务架构就其方法本身而言，既可以用于单个产品线或业务种类的领域级分析，也可以用于跨越产品线、业务领域的企业级分析；就价值而言，后一种显然对企业具有更高的价值，更值得企业去尝试、推广。

作用：业务架构的作用通常被认为是连接业务与IT的纽带，用于实现业务需求到IT的顺利传导，对于TOGAF等企业架构理论来说，业务架构也承担着将企业战略落地的职责。

“数字化”转变
转变当然不是让所有人都去跨领域学习IT技术，全去当“技术能手”，而是转变思维方式，架起一道跨越“数字鸿沟”的桥梁，这就是业务架构的核心作用。业务架构可以帮助业务人员整体化、结构化地思考问题，从业务和系统的整体视角，附带一些对技术的基础了解，如分层理念、服务化、微服务化等，去理解业务和技术；同时还能够帮助技术人员理解、归纳业务人员的想法和目标，从而让业务和技术能够处于同一个语境之下，使用同一种“语言”工作。

业务架构与IT架构的关系

业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构与其他架构一样，其目的也是要降低复杂度，从更好地规划和实现系统，因此TOGAF将业务架构归属于IT战略部分。但是从笔者的实践经验来看，业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变，所以，应当将业务架构从IT战略中独立出来，更多地面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构要想真正承担起这一职责，还需要改进、简化业务架构设计的方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，“熵增”一定会将已经建好的架构秩序回归到混沌状态。

TOGAF框架将业务架构视为IT战略的一部分，但事实上，业务架构应当是企业战略而非IT战略的一部分，它不同于通常意义上的业务需求，而是企业业务战略的实现方法。因此，业务架构范围是可以大于IT架构范围的，可以包含企业战略的非系统化部分，是企业业务的全景描述。

IT架构

IT架构的4种架构的特点以及关系具体如下。

1）应用架构重点关注的是功能布局，与业务架构的关系非常紧密，可以称其为业务架构设计的“紧后工序”。 2）技术架构主要关注分层结构，对于大型业务系统来说，一个逻辑分层很可能要通过多种平台才能实现，因此还会在分层中加入平台规划。技术架构与业务架构的关系不像应用架构那么直接，主要是通过对业务特征、业务量等多种因素综合考虑分层的合理性和平台选型，通常业务架构设计不会涉及这部分工作，但业务架构人员应当了解本企业的技术架构及特点。 3）数据架构中有一个重要的组成部分是数据模型，数据模型与业务架构关系密切，甚至可以归类为业务架构的组成部分。 4）安全架构与业务架构的关系一般不是十分紧密，但是目前安全架构设计的一个发展趋势便是在向业务架构靠拢，或者说是向企业战略靠近，以使得安全架构设计更贴近实际业务需要，符合企业发展方向，而不再局限于传统的网络安全、信息安全等防护型工作，需要体现出更多的“规划”特征。

业务模型

模型是所研究的系统、过程、事物或概念的一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。
模型最重要的就是抽象，但模型也可以是具象的，可以是实物，比如楼盘模型
模型就是一种表达形式，其实我们所说的话也可以视为一种模型，它是我们头脑中某种想法的表达，表述的过程即可看作是建模的过程，同时我们的表述还遵循了一定的语法规则。

如果只是针对一个产品，那么业务模型可能就是对产品的设计、生产、销售、使用、售后管理过程的描述，其中还要包含所有参与方的目标、活动、角色、职责等。如果针对的是一个大型企业，那么业务模型的范围就可能包含多条产品线，每条产品线都有不同的业务过程，而所涉及的参与方也会更多、更复杂。
业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形“收入-成本-利润”。

几个模型

ISO9000模型

申请ISO9000质量认证的企业，通常要绘制企业的业务流程图，流程图的样式为垂直职能带型，通常使用Visio工具进行绘制。

BPMN模型

BPMN（Business Process Model and Notation）即业务流程建模与标注，是由BPMI（The Business Process Management Initiative）开发的一套建模标准语言。OMG于2011年推出BPMN 2.0标准。
作为建模语言而言，BPMN的表达能力很强，其元素的核心集包括含事件、活动和网关在内的流对象（Flow Objects），含顺序流、消息流以及关联在内的连接对象（Connecting Objects），含数据对象、文字注释和组在内的人工信息（Artifacts），以及作为图形化容器的泳道。

UML

UML（Unified Modeling Language，统一建模语言），UML是非专利的第三代建模和规约语言。
UML体系中包含了3个主要的模型，具体说明如下。
1）功能模型：从用户的角度展示系统的功能，包括用例图。
2）对象模型：采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图。
3）动态模型：展现系统的内部行为，包括序列图、活动图、状态图。
架构不等同于模型，模型也不等同于架构，不要将二者混为一谈，架构相当于思想，模型只是表达。

注意点

“一切不考虑落地的架构设计都是耍流氓”，杜绝成为“PPT模型师”。
架构不等同于模型，模型也不等同于架构，不要将二者混为一谈，架构相当于思想，模型只是表达。
业务架构设计不能代替需求分析。
MDD（Model Driven Develo-pment，模型驱动开发）

业务架构设计

设计和落地两个不断交替上升的过程

设计过程为从企业战略分析出发，通过梳理企业目标，发掘能力需求（既可能是企业自身业务与技术水平发展产生的主动能力需求，也可能是科技导致的业态变化、竞争压力产生的被动能力需求）；再通过价值链分析方式，构建企业整体能力布局（即业务架构），并在分析过程中，将能力需求放入能力布局中，并以此在业务层面落地战略、检验战略的可行性，甚至调整战略。落地过程主要为通过业务架构驱动IT设计、协调实施过程，建立业务架构元素与IT设计元素之间的联系，并在实施中对业务架构进行基于实现的最终调整，以确保业务架构与IT实现之间的一致性。

优秀的业务架构实践不能仅单纯地停留在业务分析层面，也不能只满足于业务能力的组件化聚类，而是要时刻关注新技术、新业态的变化，适时引入新理念、新方向，使之具备与时俱进的能力。

企业战略分析模型

BMGovernance公司设计的企业战略分析模型↓

该模型从企业愿景、使命这种相对宏观的概念入手，向下分解出可度量的目标，愿景、使命和目标这3部分作为“屋顶”，描述的是企业为自身发展所设定的目标和成功的标准，无法衡量的目标只能是个精神口号，不能转化为行动。这并不是说不能喊口号，而是说这个口号必须是能够被分解成可以指挥行动的具体度量。
战略是为了完成上面提到的目标所需要采取的路线、方法；战略能力则是为了完成这一策略所需要的能力。

见贤思齐-对标分析

无论是使用“SWOT”分析方法、波特的“五力分析”方法，还是不靠任何方法论的“硬想”，都无法抑制将其与行业内、甚至跨行业的领先实践进行对比的“冲动”。
很多人将对标分析的好处定位于快速学习领先实践，其实这种想法存在两个误区：

（1）对领先实践的研究多是表象研究，很难充分了解其机理。此外，企业的发展是有时间过程的，一个优秀的表象是经过了什么样的过程形成的，其实很少有人能说得清楚。（2）企业对自己的认知其实是有限的，很多问题并没有深入挖掘根本原因和产生环境，而这两点对于形成正确的对标分析结论却是非常重要的。为了提升对标的针对性，首先还是要从自己身上下功夫，只有真正的在内部无法攻克的问题才值得去对标。

在企业战略设计方面切不可简单照搬、盲目引进，光在“别人家的事情”上下功夫，导致无效对标，甚至让对标分析“带偏”了自己。

组织结构梳理

对组织结构的梳理，在需求分析过程中也会经常遇到，内容包括部门职能、部门关系、岗位等。就信息收集而言，业务架构设计在操作方面并没有什么特别之处，区别在于，业务架构设计的着眼点是企业级能力规划，希望能够突破壁垒、形成合力。
“康威定律”。Melvin Conway于20世纪60年代后期确定的“康威定律”告诉我们，任意一个软件都能反映出制作它的团队的组织结构，这是因为人们会以反映他们组织形式的方式工作。项目团队的组织结构中的优点和缺点都将不可避免地反映在他们制作的系统中。这个规律延伸到需求方身上也一样适用：需求方的组织结构不可避免地会影响到系统的组件结构。
在企业内部，部门利益是部门需求的天然边界，即便要做企业级，各方肯定也是要先说清楚自己的需求，再去考虑别人的需求，“种了别人家的田，荒了自家的地”是绝对不行的。部门利益是做企业级的最大障碍，跨越这个障碍是对业务架构师设计能力的最高挑战。

组织的沟通方式主要是正式和非正式两种，其中，正式沟通在大企业中最常见的方式就是开会。如果会议效率难以保证，一个问题久拖不决，就会产生两种结果：一是项目组担心工期延误直接改变架构方案；二是采用非正式沟通方式，项目组间通过私下交流解决问题，而后者也极有可能是以改变架构方案为代价的。

业务流程分析

“企业战略——组织结构——业务流程分析”
管理学上分析企业竞争力通常多使用价值链模型。价值链（Value Chain）的概念首先由迈克尔·波特（Michael E.Porter）于1985年提出。
价值链主要描述的是企业价值的创造过程，引入价值链分析主要是为企业横向审视自身的业务能力提供分析框架。
价值链主要包括基本活动和支持性活动，基本活动是指主要生产过程，支持性活动则是指对基本活动起辅助作用及维持企业基本运转的各类活动。
波特价值链↓

行为分析：业务领域和业务流程

划分业务领域：搭建好价值链这一“横轴”之后，就可以基于价值链的各个环节分析多个“竖轴”了。（横轴（价值链）和纵轴（业务领域））
划分领域其实包含了两种方式，从客户出发和从产品出发，选择哪一种，需要根据企业的特点以及企业更关注什么来决定。
业务流程的分析实际上是将一个业务领域中的所有业务处理过程按照价值链约定的范围进行分解，形成每一个价值链环节中的一个或者多个工作流。
业务领域其实是企业确定以某类产品服务某类客户的一个业务范围，在建模上，其表现为：为实现这一价值定位，企业在整个价值链上的各种业务活动的有机结合。一个业务领域实际上就是由一组业务活动构成的，业务活动中的角色和任务，体现了所有参与到价值创造过程中的组织单元的分工协作关系。

数据分析：企业级数据模型

软件设计主要研究的是行为和数据，流程模型分析了行为，数据模型当然就是要分析数据了。
提起数据模型，技术类读者的第一反应可能就是ER（实体关系）图，实体关系图是我们做关系型数据库设计的基础。实体关系图是按照对业务对象的划分，将数据属性按照实体聚类，并描述实体间的关系，从而指导程序设计和数据库设计。以金融类企业常用的FSDM（Financial Services Data Model）为例，它是IBM的一个企业级数据模型，囊括了银行约80%的业务数据。FSDM将数据分为九大类，分别是关系人、合约、条件、产品、地点、分类、业务方向、事件、资源项目。
作为企业级模型，数据实体和属性都要保证唯一，做到这一点在建模中并不难，通过工具筛查就可以比较出名称、定义、取值重复的数据项，从而保证数据的唯一性。但是业务架构的重点在于生产阶段的管控，而非建模阶段。生产阶段要通过数据管控平台或工具对数据字典进行严格管理。

组件分析：行为与数据的结合

流程模型与数据模型是描述业务的一对“难兄难弟”，流程模型表达的是“处理”，数据模型表达的是“输入”和“输出”，合起来就是计算机的基本工作流，这在大部分软件设计方法论中都是共识。
如果将该业务系统化，就会变成如下的问题：实现业务活动的计算机程序是在什么样的场景（事件）下开始执行的，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织、角色）执行，执行之后将会产生哪些数据（实体）。任务会直接处理数据，而这种处理通常可分为增加、修改、删除、查询四类操作。
一个业务领域是由一组活动构成的，而这些活动又是分布在价值链的不同环节中。如果粗糙地划分业务组件，则将每一个价值链环节设为一个业务组件也未尝不可。对于业务复杂的大型企业而言，组件的内聚性一般都很差，所以我们需要进行更为精细的划分。数据模型包含主题域这个层级，即将关系较近的数据实体聚合成一个分类，对于这种关系我们可以给出一个主题名称。

小结

业务架构的设计包括：价值链、业务领域、业务流程（即活动、任务、角色）、业务数据和业务组件5个关键元素。
价值链代表了构建企业能力统一视图的“横向”结构，每个价值链环节中均包含了若干个业务流程；业务领域代表了构建企业能力统一视图的“纵向”结构，描述了各类业务流程应如何通过组合实现领域级的业务目标。
业务流程即业务活动，业务活动是由不同角色分别完成的若干任务组成的，任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），形成包含行为和数据的业务组件，组件代表了企业的某一类业务能力。
从下往上看，业务组件中业务能力通过任务与活动的关系、活动与领域的关系，表达了对业务领域的支持，这就开放了企业在每个价值链环节中的所有能力。
业务架构整体逻辑关系图↓