企业架构概述及业务架构详解

Posted 2023-04-10 天秤座的架构师

编辑导语：企业架构可以辅助企业完成业务及IT战略规划，还是企业信息化规划的核心，也有助于个人职业的健康长远发展。本文作者对企业架构的全景以及业务架构设计进行了分析，感兴趣的小伙伴们一起来看一下吧。

1）对公司而言

企业架构可以辅助企业完成业务及IT战略规划。在业务战略方面，它定义企业的愿景/使命、目标/目的/驱动力、组织架构、职能和角色；在IT战略方面，定义业务架构、数据架构、应用架构和技术架构，是IT战略规划的最佳实践的指引。

企业架构是承接企业业务战略与IT战略之间的桥梁与标准接口，是企业信息化规划的核心。

2）对个人而言

有助于职业的健康长远发展，比如成为CIO，首席信息官通过指导对信息技术的利用来支持公司的目标，具备技术和业务过程两方面的知识，常常是将组织的技术调配战略与业务战略紧密结合在一起的最佳人选。

一、企业架构全景图

1. 企业架构的模块划分和主要工作内容

企业架构包含了四部分，BA（Business Architecture，业务架构）、DA（Data Architecture，数据架构）、AA（Applications Architecture，应用架构）、TA（Technology Architecture，技术架构）。

企业架构由全局战略规划驱动，我们来看下战略、BA、DA、AA、TA五者之间的关系。

图 1-1 战略、BA、DA、AA、TA的执行顺序

如图所示，战略、BA、DA、AA、TA实际位于以下三个层次上：

• 公司战略
• 业务架构
• 方案架构

这五者的核心关系，可以概况为以下几点：

• 战略是公司高层设计，战略能力的建设就是业务架构师的需求
• 业务架构师的工作时“战略进，业务架构出”
• 业务架构是业务架构师的设计，却是数据、应用、技术架构师的需求

环环相扣，上层驱动下层，下层支撑上层。

                                        图 1-2战略、BA、DA、AA、TA的关系

2. 从战略到架构，再到实施的实际过程

通过上面的内容，我们知道了战略、业务架构、方案架构的关系，下面我们看下实际工作中架构路线图和实施规划环节是如何操作的。

                                                     图 1-3 战略到架构的实施过程

执行的要点是钉到岗位（左侧），落到文档（右侧），细到机构调整、技术采购、项目研发等工作包。主要有以下环节：

• 战略：公司管理层牵头、规划发展部全程支持，产出物：《xx-xx年战略规划书》
• 业务架构：信息科技部的架构师团队中的业务架构师负责，产出物：《业务架构书》
• 方案架构：信息科技部的架构师团队负责，产出物：《技术方案书》
• 架构路线图：涉及预算，CI0牵头制定、董事会批准，产出物：架构路线图
• 实施规划：CIO牵头制定，产出物：实施计划
• 项目管控：采取研发的项目由PMO负责，采取购买的项目由总经理办公室负责

这里需要补充说明的一点是，实施计划不仅仅是从“架构蓝图到研发”的计划，也是从“架构蓝图到IT与非IT的方方面面”。

• IT方面：支持业务架构蓝图所需的所有“IT能力”有哪些？项目是研发还是购买？相应识别技术采购工作包、人员培训工作包。
• 非IT方面：支持商业蓝图所需的“组织能力”有哪些？相应识别机构调整工作包、新建部门工作包、人员培训工作包。

二、战略驱动的业务架构设计

1. 业务架构（BA）是什么？

对于业务架构，OMG业务架构组给了如下定义：业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义了企业做什么，业务流程定义企业怎么做。

具体而言，就是：

• 业务功能是由业务流程实现的
• 业务流程由业务步骤、业务角色、业务数据、业务事件、业务规则组成。

2. 业务架构出现的背景

我们分别从国外国内来了解一下，业务架构出现的背景，便于我们更好的理解业务架构的使用场景，业务架构是跨部门跨组织的业务需求，单个小系统的生命周期，根本就没有业务架构环节。

1）跨系统规划——业务架构在全球出现的背景

国外软件系统经过长期发展，在经过多年实践后，1962年发表于哈佛商业杂志的《信息系统总规划》这篇文章，拉开了跨部门、跨组织需求规划的序幕。此后多年，IBM等企业进行了很多实践。

1982年，IBM公布了业务系统规划（Business System Planning，BSP）方法论。这是个重要事件，对业界产生了大而持久的影响。

此后多年，业务架构快速发展，如Togaf、FEAF等。

以上历史告诉我们，业务架构脱胎于跨系统、重视跨系统需求。站在开发者的角度，业务架构就是跨部门、跨组织的业务需求。

2）信息孤岛——业务架构在国内“火”起来的契机

国内有个现象，一提到业务架构，就会大谈信息孤岛。这是为什么呢？因为国内真正开始重视业务架构设计，就是从解决信息孤岛的痛点开始的。

21世纪初，国内的信息化进程从部门信息化推进到了企业信息化。企业部门间的（集团子公司间的）协同联动需求，带动了IT信息系统间的信息共享和协同联动需求——同时产生了信息孤岛问题（财务、人力资源、采购、销售、OA、CRM各自为战）。

因为信息孤岛所具备的三大弊端，促使业务架构在国内火了起来，以下是三大弊端：

1. 无法协同—低效
2. 重复建设—浪费企业资源
3. 贻误发展时机—这个影响最大，头部企业错失风口也会被赶超、变得落后

那如何解决信息孤岛的问题呢？

在一系列系统分头建设之前，先设计业务架构，定义统一蓝图，这是根本。数据一张图、数据共享、流程打通、服务编排，都是围绕统一蓝图具体展开。

业务架构是跨系统的，那么它和子系统的关系是什么样的呢？

图 2 – 1业务架构和子系统的关系

图中的大V、小V分别表示什么呢？

• 一个大V，表示方案的业务架构、分期实现、上线验收。
• 两个小V，表示子系统的需求分析、程序开发、系统测试。

大V部分，是总体方案的生命周期。在大V的需求阶段，必须研究和定义清楚跨部门、跨组织的业务需求，这些需求往往是跨系统的。例如，客户报修业务功能明显需要呼叫中心系统、CRM系统、工单系统协同联动，才能支持客服接听电话、确认客户资料、记录报修内容、派遣维修工程师上门这一连串操作。

小V部分，是某一个系统的生命周期。在小V的需求阶段，必须分析和定义清楚这一个系统的需求，这些需求往往是系统内的。例如，CRM系统负责客户资料管理。

综上所述，方案级、子系统级这两级生命周期是同时存在的。举个典型的例子，某公司要做一个ERP系统，他会怎么做呢？

1）立项阶段

由于方案涉及的范围广、部门多，所以有必要做业务架构设计。这时，由业务架构师担纲业务架构设计，并提交《业务架构书》。

2）一期工程阶段

假设主要涉及系统A的需求、开发、测试等。

这时需求分析员冲上去，负责《系统A需求说明书》，当然需求分析员要参考上游的《业务架构书》整体约定。

注：这里只所以说是假设，是因为实际操作中可能是实现某个业务功能需要同时开发系统A、系统B、系统C的部分功能，并不是说一期工程的所有功能必须隶属于同一个系统。

3）二期和三期功能

假设主要涉及系统B的需求、开发、测试等。

这时这时需求分析员冲上去，负责《系统B需求说明书》，当然需求分析员要参考上游的《业务架构书》整体约定。

3. 实践攻略：业务架构的实际工作内容

业务架构要想成功，首当其冲的是，架构师要做正确的事，即在业务架构的实际工作内容上有充足的经验，不能遗漏。

相反，业务架构师分析环节的缺失，意味着业务架构蓝图规划项的缺失，影响从投资角色到方案设计，到实施规划，再到IT工作包和非IT工作包识别等所有后续工作。

业务架构 = 业务功能 + 组织结构 + 业务流程 +业务数据

业务架构的实际工作内容有哪些呢？

业务架构的前身是1982年IBM发布BSP等跨系统规划方法，所以，业务架构本质上是跨系统规划。

但是，业务架构的内容远远超过了跨系统需求分析这个范围，覆盖跨系统业务架构蓝图规划这个更大的范围。究其原因，是业务架构必须发挥从战略向实施过渡的桥梁作用—上街公司战略，下接IT实施和非IT实施。

不错，业务架构也涵盖了非IT部分的蓝图！

我们来看下细化的业务架构实际工作模型。

                                                     图 2 – 2 业务架构蓝图

就大的方面而言，业务功能定义企业做什么？组织结构定义谁来做？业务流程定义怎么做？业务数据提供必要的支撑，因此，业务功能、组织结构、业务流程、业务数据四者，构成了业务架构蓝图的核心。

同时，商业模式揭示的是企业产品、企业核心资源、客户、伙伴、渠道、成本、利润之间的本质关系。商业模式这个现代工具，也是业务架构蓝图的必须规划项。

就小的方面而言，第一，业务渠道在哪里？组织结构是围绕部门、角色、职能展开的，而组织结构、业务渠道、合作伙伴是紧密相关的。所以，业务架构师在梳理组织结构的同时，应结合渠道战略和合作伙伴战略，定义业务渠道规划，定义合作伙伴规划，这些都是业务架构蓝图的“一等公民”。

第二，价值链在哪里？价值链模型是对一个企业所有生成经营活动的总体描述，是规划业务架构蓝图时的必做项目。可以对业务功能进行三级划分、层层分解：

• 顶级分解—做价值链模型
• 一级分解—做功能域分解
• 二级分解—做功能子域分解

第三，业务流程 = 主干流程 + 分支流程 + 业务规则：

主干流程通用性强，不易变。例如：买火车票时，“选票-抢票-支付”这个流程是稳定的。

分支流程个性化强，常变化。例如，选座分支流程，靠窗、不靠窗、坐票、卧铺（上下中铺），买儿童票、成人票、学生票也要进入分支流程。

业务规则细节性强、碎片化，所以建议一边定义业务流程，一边定义相应的业务规则。

综上，业务架构蓝图的内容应该明确！全面！直观！详细！

上面我们学习了业务架构包含的内容，可能不够直观，我们通过案例来加深我们对每个模块的理解。

1）业务架构蓝图五要素

我们借助业务架构蓝图五要素，管窥一下中国铁路12306平台的业务架构。

• 目标业务功能：线上购票、线上支付、线上退票等
• 目标组织结构：在原组织结构基础上，新建IT运维中心
• 目标业务流程：先登录、后抢票、再支付、超时未支付则释放票源
• 目标商业模式：线上购票，省事省力（这个仅是价值主张）
• 目标业务数据：用户账户、列车时刻表、坐席数据、订单、支付记录等

2）业务渠道、合作伙伴、价值链

下图分析了证券公司的业务功能与相对应的业务渠道：

图 2 – 3 用价值链来分析业务

价值链包括核心业务层和支撑层，这里的核心业务层属于价值链对业务功能和服务的顶级分解。

经纪业务包括客户开发、交易功能、客户服务，业务功能分为三个层级，顶级分解、一级分解、二级分解，这三个是业务功能的顶级分解。

从图中我们知道该证券公司有四个核心业务，分别是经纪业务、自营业务、资产管理、企业融资。

相关传统渠道，主要是营业部柜台；相关电子渠道，可以是综合服务门户、客户端、手机APP等；公司员工可以通过综合管理门户完成日常工作与协调。

4. 实践攻略：战略驱动的业务架构的步骤

在做规划时我们常采用GAP分析法，先确定当前现状，然后给出我们的期望，分析目标和期望的差距。如果有人和一个新手这样说，可能是不够的，你至少需要回答以下几个疑问：

• 业务架构师具体要分析什么？怎么才算是战略驱动？——能否具体到政策文件？战略方针？市场调研？友商对标？
• 从战略到蓝图，中间的逻辑是什么？——能否具体到小目标分解？小策略制定？
• 我们首先应该怎么做？——就连一个小的进销存系统，也要先进行业务调研，不是吗？

1）落地：设计步骤

我们看下作者分享的战略驱动的业务架构（BA）设计三步法。

图 2 – 4 业务架构的设计步骤

图中的三大步很明确，也非常贴近实际。

优点1：明确的战略驱动起点。方法中明确了三种战略驱动因素（Drvier）的类型，因为实际中就是国家政策、企业战略、对标友商者三者之一触发了后续的调研、规划与实施。

优点2：明确的调研环节，在第一步中，包含了调研环节。

优点3：强调了从战略到蓝图的过渡逻辑，在第2大步中，扎扎实实地规划好业务架构目标/策略，才能确保蓝图充分支撑战略。这一步属于高层级业务架构设计。

优点4：目标蓝图与Gap分析并重，在第3大步。

设计BA目标蓝图这一步属于低层级业务架构设计，其中Gap环节是必须环节，我们必须识别出业务架构的增量有哪些，给出对应的实施措施。

Gap分析的价值在于，它是持续进行架构治理所必需的，除了BA规划环节应用，在AA、DA、TA设计环节也均有应用。

2）要点：明确Driver，做好调研

业务架构设计必需做好的第一件事，就是100%明确战略驱动因素是什么。

业务架构设计必须做好的第二件事，就是调研。通过调研，广度上理解企业的宏观环境、行业趋势，纵深上理解战略的前因后果、来龙去脉、横向上理解企业的竞争格局、友商动向。

粗看，调研范围很广，让人理不清头绪。细看却有规律，主要三条线，分别是管理层访谈、战略的来龙去脉、可借鉴案例。

图 2 – 5 业务架构设计需要调研的内容类别

3）要点：从战略到蓝图的内在逻辑

从战略到蓝图的内在逻辑，由四个概念支撑起的骨架：

1. Driver：战略驱动因素
2. Goal：业务架构目标
3. Strategy：业务架构策略
4. Blueprint：业务架构蓝图

这是一个大型企业，推进数字化采购转型如何从战略到蓝图的构建逻辑，相信它有助于我们的理解以下几点。

图 2 – 6 战略到蓝图的内在逻辑

1. 图中从上到下是Driver、Goal、Strategy、Blueprint四层体系
2. Driver层：1个战略驱动因素，公司向数字化转型
3. Goal层：3个业务架构目标，可以理解成数字化转型的具体目标分解
4. Strategy层：10项业务架构策略，理解成3个Goal需要提升的能力。最关键的一点是，10项策略完全围绕业务架构蓝图5要素展开，如组织业务架构提升、业务功能提升等
5. Blueprint层：按业务架构蓝图五要素定义蓝图，这是业务架构师的主要工作

综上所述，从战略到蓝图的内在逻辑主线是：确定Driver—目标分解—策略设计—蓝图定义。逻辑明确，创新有据。

只有业务架构师真正洞悉了战略意图、准确领会了战略动机，之后的业务架构设计工作都是有迹可循的，工作量再大，也不可怕。

4）工具：GAP分析

• 内容1：列出基线业务架构，以及目标业务架构的高层描述
• 内容2：对比分析，识别GAP——业务能力差距、IT能力差距

5. 实践案例

1）数字化转型–确定Driver，做好调研

①推进：确定Driver

项目假定为：某铁路数字化服务转型工程。

业务架构师（张三）知道业务架构的Driver是整个业务的起点，必须找准、吃透。

张三了解到，数字化转型工程的Driver是公司刚制定的《公司战略规划》。

《公司战略规划》中阐述了数字化服务转型的背景：近年来，互联网技术的发展，提高了各行各业的服务水平，极大方便了人们群众的衣、食、住、行、医、学、玩等方面。从企业的角度而言，借助互联网、大数据等技术，积极推动数字化转型，拥抱以客户为中心的服务模式，能搞提高客户满意度和企业竞争力。

《公司战略规划》中和数字化转型战略的核心表述是：树立以人为本、客户至上的服务理念，创新服务方式，完善服务标准，推动数字化服务转型，提高服务水平。

②推进：做好调研之管理层访谈

管理层访谈不是让业务架构师去了解行业，而是要领会管理层的关注点、主要看法。

通过访谈，业务架构师应了解：

• 现状：管理层认为当前的主要不足在何处？ 比如订票不方便
• 目标：管理层希望变革达到的目标是什么？ 比如管理层希望建立网上综合服务门户
• 措施：管理层认为可能的举措有哪些？比如运用互联网
• 政策：管理层非常关注哪些相关政策？
• 对标：管理层特别关注的对标企业是谁？如：国外企业售票的做法
• 其他：管理层的其他关注点，如：提升企业形象

③推进：做好调研之可借鉴案例研究

研究可借鉴的最佳实践、最佳案例，也是调研的必做内容。

究其原因，业界每个阶段的最佳实践、最佳案例，都反映了业界当时的实践水平。所以，如果业务架构师收集并分了业界当前最佳实践案例，就可以在自己负责的架构设计中更好的把握设计方向、制定设计标准。

2）数字化服务转型—确定BA目标与策略

业务架构目标和策略包含以下两方面：

• 内容1：阐述业务能力短板，确定业务架构目标
• 内容2：阐述在组织结构、业务流程、业务功能、商业模式、渠道创新等方面的具体策略。并说明依据，如国外水平、对标分析、用户调查、用户画像、数据统计、技术趋势、机会节点等。

①推进：差距分析

Baseline Business Architecture：

图 2 – 7 基线架构

Target Business Architecture：

图 2 – 8 基线架构

上述案例，我们通过GAP分析，识别了业务能力差距和IT能力短板，从而识别业务架构目标与策略，这是采用自底向上的方法。

为我们后续环节做准备，比如我们识别出了核心业务需要增强的包括销售、客运、货运、清算、售后，新增的包括增值业务，在制定在业务功能、业务流程、业务数据、组织结构、商业模式模块给出对应的策略。

如：从上图价值链分析中看到，我们新增的业务需求是增值业务，通过电商业务、旅游代理可以实现，再进一步想一下，就会知道我们的目标是增收，接着可以自顶向下思考，增收除了电商业务、旅游代理，我们还可以做保险代理，通过服务门户这个渠道触达用户。

②推进：确定目标与策略

只有扎扎实实地规划好业务架构目标与策略，才能确保后续业务架构蓝图定义充分支撑战略。

确定业务目标与策略环节，是业务架构设计的高层部分。后续的业务架构蓝图定义，是业务架构设计的低层部分。前者引领者后者的发展方向，由此可见“确定业务架构目标与策略”这一环节的重要性。

这一步，有三种做法：

1. 自顶向下：将Driver分解为子目标，将子目标映射到业务架构策略
2. 自底向上：通过Gap分析，找到能力短板，从能识别业务架构目标与策略
3. 上述两种做法相结合，循环展开，互为验证

铁路系统数字化转型，提高服务水平是Driver，如何才能达到这个终极目标？

答案是：

• 便民：例如提供在线订票服务，呼叫中心服务
• 增效：用取票机、检票机提高检测效率和准确性，同时也降低了用人成本
• 增收：提供服务门户

图 2 – 9 确定目标与策略

3）数字化服务转型—定义BA蓝图（组织结构）

图 2 – 10 组织结构视图的内容

组织结构视图包括三个模块，组织结构、业务渠道、合作伙伴。

组织结构及改进主要描述部门设置、岗位设置、岗位职责等；合作伙伴及改进主要描述加强与供应链上下游的合作伙伴之间的关系。业务渠道创新也是业务架构设计的常见策略，下面会举例说明。

组织结构：下图是运用GAP分析的方法，画出当前组织结构和目标组织结构，并表示出变动点。

图 2 – 11 组织结构GAP分析

新手业务架构师往往认为组织结构没啥好设计的，其实恰恰相反，一旦组织结构需要变革，必然影响重大。

从上图，我们可以看出来，之前企业自己做IT开发，目前公司计划在做开发的同时，自己也做IT运维。相应的，企业组织结构新增了IT运维中心。

业务架构师应尽早明确组织结构的可能变化。因为无论是新建部门，还是部门增强、人员能力增强，都属于TOGAF中的能力增量，是需要后续非IT工作包实现的。

不仅如此，组织结构的变化还影响整个企业的治理结构，从经营管理，到制约监督，再到绩效考核。

总之，业务架构师虽然经常被当做跨系统软件需求分析师降级使用，但真正承担业务架构蓝图规划任务的业务架构师，是必须能扛得起很多“非IT”规划的。

4）数字化服务转型—定义BA蓝图（业务渠道）

渠道在百度百科上的解释是“比喻达到某种目的的途径”，业务渠道就是用户为了达成业务目的的途径。如下图，列车长通过补票终端这个渠道帮助用户完成补票，客运公司通过大屏幕告知乘客车次信息。

业务渠道创新示例：

图 2 – 12 业务渠道设计案例

网站、手机APP、补票终端、大屏实现了购票、补票、查看车次信息线上线下联动，提升了用户体验和公司内部效率。

由上图可知，业务渠道不是完全孤立的业务架构蓝图规划项，它和业务流程、业务功能、组织结构是相互呼应的。因此，我们规划业务渠道时，也应考虑这些。

关于渠道联动，有同行这样总结：

• 低层次：信息孤岛，竖井林立，客户在手机上买了票，在PC上竟然查不到
• 一般层次：信息共享，多个前端共用统一的后台系统
• 高层次：渠道联动，流程拉通，多岗位、多前端、多应用之间流畅的流程协同

5）数字化服务转型—定义BA蓝图（业务功能）

图 2-13 业务功能视图

企业是由一系列为顾客制造价值的活动和功能组成的，我们的业务功能就源自于可以为顾客制造价值的活动和功能。

企业的价值链展示了企业的设计、生产、营销、运输等为顾客创造价值的一系列活动、功能以及业务流程之间的连接情况。价值链有两个主要的组成部分：

• 核心业务：创造主要的顾客价值
• 支持活动：为核心业务提供支持服务

继续来看运输公司数字化服务的案例，业务架构师，面对运输企业数字化服务转型的任务，经过潜心研究，给出了下图的价值链划分结构。

图 2 – 14 运用价值链分析业务功能

有的同学可能会有疑问，为什么会在核心业务模块同时存在客运和货运两个区别较大的业务类型？在实际工作中可能只负责客运、货运其中一个模块。

前面我们业务架构出现的背景也有提到，在国内业务架构是为了解决信息孤岛发展起来的，业务架构师就是要在全局做规划，而不是梳理单个系统。

以上我们已经整理了价值链，现在我们要分解功能域了，下图是一级功能域分解图：

图 2 – 15 一级功能域拆分

接下来，做业务能力Gap分析，我们可以看到新增的一级功能域有4个，增强的一级功能域有13个。

通过价值链分析到一级功能域划分的转变，我们会有以下收获：

① 价值链分析模型为后续功能域划分奠定了基础，管理支持+核心业务这个业务功能呢域划分框架确实很好用，并且广受业界认同，在沟通的过程中自然也容易被其他人接受。

②类似“上车前、上车中、下车后”时间轴思维，是业务架构师必备的分析技能，同时，是甲方企业领域专家们经常使用的分析习惯。

业务架构设计不仅要定义出目标架构，还要使用GAP分析法，识别出需要增强的架构能力，为后续实施做准备。具体包括业务功能变化与增量、组织结构变化与增量、业务流程变化与增量、业务数据变化与增量。

6）数字化服务转型—定义BA蓝图（商业模式）

商业模式揭示的是企业产品、企业核心资源、客户、伙伴、渠道、成本、利润之间的本质关系。简单说，就是为什么同样的事，有的企业行，有的企业不行。

制定商业模式时并不是说全局只有一个商业模式，我们可以根据我们的目标分别制定商业模式，比如上述案例中，该铁路运输公司的目标有三个：便民、增收、增效，我们就可以设计三个商业模式。

就铁路企业的数字化服务转型而言，要便民，应支持随时通过网络、电话、手机App获取企业服务。

图 2 – 16 目标为便民时的商业模式

就铁路企业的数字化服务转型而言，要增效，可以借助硬件设备和智能控制系统，促进取消、检票等环节的数字化转型，提升效率。

图 2 – 17 目标为增效时的商业模式

商业画布，借助九个小格子，构建了简介高效的系统化思维环境，是个了不起的发明。

从上述例子可以看出，商业模式有如下优势：

• 利于有效设计，可以激发服务创新、流程创新、跨界合作等好的创意
• 利于有效汇报，商业模式凸显了“为什么这么干”的内在逻辑

个人认为，商业模式融合了BRD和MRD的内容：

• BRD：商业需求文档，关注为谁（客户细分）、解决什么问题（价值主张）、需要做什么（关键活动）、花费什么资源（关键资源）、性价比（成本/收入）如何
• MRD：市场需求文档，关注消费者怎么触达（渠道通路）、怎么获得合作伙伴

7）数字化服务转型—定义BA蓝图（业务流程）

业务流程视图是应用架构的输入，也是业务架构中最落地、篇幅最大的章节。

作者在文章中对业务流程的协作方法进行了论述，结论是简单的业务流程可以采用流程图的方式绘制，业务流程分支较多且复杂的强烈建议使用文本化描述。

业务流程定义规范：

• 第一部分：业务功能概述，业务功能通过主干流程和分支流程实现，要点是“1个主干+N个分支”方式的流程分解

• 第二部分：主干流程，要点是“阶段化+步骤化”，并附每步业务或数据模型规则

• 第三部分：分支流程，要点是“注明在主干流程的分叉位置”，并附每步的业务或数据模型规则

• 第四部分：关键UI原型/UI流程，这部分为可选

图 2 – 18 业务功能概述

图 2 – 19 主干流程

图 2 – 20 分支流程

图 2 – 21关键UI原型：UI流程

这部分很重要，上面也有提到，业务流程视图是应用架构的输入，所以对这块再总结一下。

我们发现，分支流程和业务场景有完美的对应关系。识别分支流程，就是场景化思维。相反，如果不区分主干流程、分支流程，后续业务需求变更会波及一大片，而不是改一个分支流程这么简单了，这太不专业。

业务功能很多，业务场景更多，业务流程定义了什么呢？业务流程定义一个业务功能，其中包括多个业务场景。比如购票包括了多人购票、购买儿童票等。

业务规则多如牛毛，如何避免业务规则碎片化？围绕业务步骤定义业务规则，业务步骤可以是主干流程步骤、分支流程步骤。

关于是否使用业务流程图：越是核心的业务流程，越是分支多、业务规则多，此时建议采用文本化规范，这样呈现的信息更加全面。不复杂的业务流程，可以沿用流程图的方式。

三、总结

这篇文章对企业架构进行了概述，详细讲述了业务架构出现的背景及实际攻略，并通过实际案例加深我们对业务架构的理解。

我们来一起回顾一下文章中涉及到的概念之间的关系。

• 企业架构 = 业务架构 + 应用架构 + 数据架构 + 技术架构
• 业务架构 = 组织结构 + 业务功能 + 业务流程 + 业务数据 +商业模式
• 业务功能 = 顶级价值链 + 第一层功能域分解 + 第二层功能子域分解
• 商业模式 = 商业模式画布分析
• 业务数据 = 数据域 + 数据模型 + 数据规则

战略驱动的业务脚骨设计实战步骤，精华在于，从战略到业务架构蓝图的跨度太大，逻辑链条接不上气，所以分两步走：

• 从战略到策略
• 从策略到蓝图

微服务架构概述

微服务架构（microservicearchitecture）是一种架构设计理念，旨在通过将功能分解到各个分散的服务中来实现对解决方案的解耦。服务化是将企业资源以业务能力的形式组织起来，通过一定的技术架构对这些业务能力进行封装，形成易于消费的服务，从而实现业务能力粒度的复用、组装、维护和管理，以灵活迅捷地构筑特定业务目的的企业应用。

微服务架构特点

技术架构的目标是实现对业务发展提供有力支持，比如业务敏捷、应用弹性、持续交付。相比单体架构，微服务架构具有如下特点。

• 每个微服务应用独立部署、独立运行（独立的进程），可以针对每一个微服务应用独立扩缩容。
• 一个微服务应用内包括若干服务，服务粒度无特别标准，综合考虑复用性以及功能完整性，保持组织内部理解一致即可。
• 微服务之间通过轻量级通信协议进行交互（基于HTTP，而不是SOAP）。协议风格分为RPC和REST两种。
• 微服务应用之间通过标准的接口以及契约进行交互，每个微服务应用可以采用不同的技术栈实现。
• 每个微服务应用都可以独立发布、独立升级，而不会影响其他的微服务应用，这种方式更容易实现对业务需求的快速响应。
• 去中心化架构，服务注册中心只在应用启动时用以注册及推送服务，服务调用过程无须通过服务注册中心，而采用更高效的点对点调用（或通过第三方的服务网关路由）。

微服务治理

微服务治理的好坏决定了企业实施分布式微服务架构的成败。总体来说，微服务治理包括服务目录、服务路由、服务管控、服务监控4个部分的内容。服务治理的手段是从不同角度来确保服务调用的成功率。

• 服务目录

服务治理领域最重要的问题就是服务发现与注册。绝大部分微服务框架中引入了一个服务注册中心的概念，服务的注册与发现主要依赖这个服务注册中心。服务注册中心还需实时监听所有服务节点的健康状态，以及节点的上下线消息，及时更新推送服务地址信息。

• 服务路由

根据配置中心配置的路由规则进行服务的路由指向，既可以在调用方本地路由，也可以由专门的组件（如负载均衡）进行路由处理。服务调用并不总是一定成功的，可能的原因包括服务提供者节点自身死机、进程异常退出或者服务消费者与提供者之间的网络出现故障等。对于服务调用失败的情况，需要有手段自动恢复，来确保调用成功。

• 服务管控

提供不同环境（如开发、测试、生产）的服务隔离机制，以及不同租户之间的服务隔离。限流和降级是保护自身服务正常运行的两方面的手段。限流指的是当外部请求量太大时，进行主动拒绝（或者放入缓冲队列），确保系统不被压垮；降级指的是当依赖的第三方系统性能异常（或不可用）时，为了不被第三方系统拖垮。

• 服务监控

记录每一次服务请求的审计日志，以不同维度生成服务报表（调用量、调用时长、状态分布、错误率等）。服务追踪系统可以跟踪记录一次用户请求发起了哪些调用，经过哪些服务处理，并且记录每一次调用所涉及的服务的详细信息，通过日志快速定位是调用失败的环节。