把业务架构搞搞懂，才算敲开了理解业务的大门！

为了真正掌握业务的核心，我们需对其背后的框架进行深入探讨。这正体现了业务架构的至关重要性。业务架构不仅仅是业务的高层设计图谱，它还是数据、应用和技术架构驱动所在。随着当前数字化转型的推进，业务架构已逐渐变为跨领域流程设计的核心环节。

以运营商为例，他们有一个叫做“地址查询变更”的业务功能。为了满足这一业务需求，资管系统和CRM系统各自构建了相应的应用功能模块，但这导致了数据不一致性的问题。从业务架构的角度出发，其实我们只需构建一个统一的业务功能模块即可，这凸显出了业务架构设计的真正价值。

尽管TOGAF对此进行了阐述，但其描述略显抽象。在深入阅读温昱的《业务架构•应用架构•数据架构实战》后，我收获了诸多洞见。特此分享我的关于业务架构的看法，希望能简洁而深刻地诠释这个概念。

一、企业架构全景图

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

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

BA、DA、AA、TA的执行顺序

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

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

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

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

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

二、业务架构的定义和组成

业务架构可以看作是一个组织的"蓝图"，是对组织的价值主张、结构、策略、核心产品和服务、主要流程、资产、以及相关的外部环境之间相互关系的结构化描述。它为组织提供了一个共同的框架，用于了解业务活动的相互关系，从而实现策略，并确保业务活动与策略之间的对齐。

这种定义强调了业务架构的目的，即将策略与执行对齐，并确保组织在追求其目标时具有一致性和协调性。

基于此定义，我觉得业务架构应该包含这六大部分，分别是业务策略、价值链、业务流程、业务功能、业务数据及业务组织，如下图所示，同时给出了所以包含这六大部分的原因：

1、业务策略（why）

每个组织都需要一个明确的方向和目标。业务策略定义了组织的愿景、使命和核心价值观，并为组织提供了一个长期的、宏观的指引。没有策略，业务架构会失去方向。业务策略在业务架构中起到了桥梁的作用，它确保了组织的行动与其长期愿景、使命和目标保持一致。

在描述和组织策略内容的时候，一个常用的结构化方法是使用框架或模型，如“SWOT”分析或“PESTLE”分析。这些工具为组织提供了一种方法，帮助它们识别其内部和外部环境中的机会和威胁，并据此制定策略。以下是关于业务策略的一些常见的结构化方法：

（1）SWOT 分析

• S (Strengths)：组织的内部优势。
• W (Weaknesses)：组织的内部劣势。
• O (Opportunities)：组织所在环境中的机会。
• T (Threats)：组织所面临的外部威胁。

（2）PESTLE 分析：评估宏观环境对业务的影响。

• P (Political)：政治因素。
• E (Economic)：经济因素。
• S (Sociocultural)：社会文化因素。
• T (Technological)：技术因素。
• L (Legal)：法律因素。
• E (Environmental)：环境因素。

（3）Porter 的五力模型：评估行业竞争力度。

• 现有竞争者的竞争。
• 新进入者的威胁。
• 替代品的威胁。
• 买方的议价能力。
• 供应商的议价能力。

（4）价值主张画布：帮助组织定义其对目标客户的价值主张。

• 客户细分
• 客户关系
• 渠道
• 价值主张
• 关键活动
• 关键资源
• 关键合作伙伴
• 收入流
• 成本结构

2、价值链（what）

业务架构包含价值链是因为价值链明确地展示了组织如何创造和交付价值给其客户和利益相关者，这对于确保业务操作的连贯性和效率至关重要。

首先，最经典的传统价值链模型，就是波特创造的生产型企业的价值链模型，分为辅助活动和基本活动，现今应用时，都是进行了改造和优化的，倾向于分为支持层、业务层、战略层，如下所示：

其次，电信运营商、电网、仓储物流等基建投资占比高的企业的价值链模型，倾向于分为管理支持、运营支撑、核心业务三层，如果存在业务支撑层，那么投资规划、工程建设、运营维护这三者就放入业务支撑层，否则列入核心业务主线，下图示例了能源仓储分销企业的价值链模型。

第三，银证保、电信、电商、家电、运输等服务密集型企业的价值链模型，倾向于分为支持层、业务层，支持层经常包含财务管理、人力资源管理、客户资源管理、数据资源管理等，企业对外提供的业务多种多样，那就分别梳理在业务层，铁路运输行业的价值链分析，如下图所示：

3、业务流程（how）

在价值链提供了宏观的视角，每一个在价值链中定义的活动，实际上都可以进一步细分为一系列连续的、有逻辑关系的子活动。这些子活动构成了业务流程，业务流程深入到更为具体的活动、任务、步骤和和决策，描述了如何实际执行这些活动，为组织的日常操作和持续改进提供了必要的微观视角和详细指导。两者共同为组织的策略执行、效率提升和价值创造提供了完整的框架。

跨行业的流程分类框架（The cross-industry PCF）自1992年被首次推出以来，已经被世界各地的组织使用了20多年。最新版的PCF更新于2022年5月，它将流程分为五个层级，分别是1级-流程种类（Level 1 - Category）、2级-流程群组（Level 2 – Process Group）、3级-流程（Level 3 – Process）、4级-活动（Level 4 – Activity）、5级-任务（Level 5 – Task），示例如下：

事实上，PCF的5级流程框架，体现了业务架构的完整内容，其中level1和level2可以映射到业务架构中的价值链，即解决what的问题，level3、level4及level5可以映射到业务架构定义中的业务流程和业务功能，解决how的问题，每个企业可以根据自己的需要选择合适的流程层级。

温昱在《业务架构•应用架构•数据架构实战》中建议所有的复杂核心业务流程都采用文本化描述，其以订购火车票为例说明流程的描述方法，包括主干流程和分支流程，主干流程为购票流程，如下图所示：

分支流程为多人购票、购买儿童票、购买接续换乘票、选座、没选到、无列车、过滤查看结果、查看经停站信息等等。

值得关注的是，订购火车票既可以看作流程，也可以看作活动，具体取决于从哪个角度或粒度来看待它。当我们在更高的粒度上，例如在一个价值链中，描述交通运输部门的总体业务时，"订购火车票"可能被视为一个单一的活动。这是因为在这个粒度上，我们可能不关心每个步骤的具体细节，只关心主要的业务活动，当我们深入到更细的粒度，"订购火车票"可以被看作是一个流程，因为它可以进一步分解为多个连续的任务，以上为了说明流程的描述方法，就把订购火车票看作流程。

4、业务功能（how）

业务架构需要包含业务功能，因为业务功能明确地描述了组织为实现其业务目标所需进行的关键活动和任务。它们为业务流程、策略和目标提供具体的上下文，并确保技术和操作设计与组织的核心需求和能力保持一致。此外，通过理解业务功能，组织能更有效地确定和优化其资源、过程和技术解决方案。

通常情况下，一个业务流程会包括多个业务功能。举例来说：电商平台的"订单处理"业务流程可能包括以下业务功能：客户身份验证、库存检查、付款处理、订单分派、商品发货、发票处理等，如下所示：

然而，在复杂的业务环境中，有些业务功能可能会跨越多个业务流程。例如，“客户身份验证”这个功能可能不仅仅在"订单处理"流程中使用，还可能在"退货处理"或"客户服务"等其他流程中也被用到。

因此，从某种程度上说，业务流程和业务功能之间是存在多对多的关系的，即一个业务流程可以涉及多个业务功能，而一个业务功能也可以被多个业务流程所使用。但更为常见的情况是，一个业务流程包括多个业务功能。

在温昱的《业务架构•应用架构•数据架构实战》一书中，指出业务功能>业务流程，即一个业务功能包括多个流程，对此我有不同的看法。

我们常常也会混淆业务功能、业务能力和应用功能的区别。

业务能力与业务功能相比，具有更高的抽象程度和稳定性，它主要关注“做什么”而非“如何做”。例如，贷款审批被视为银行的核心业务能力，但它并没有细述具体审批的步骤；而信用评分检查则属于业务功能，因为它详细阐述了评估客户信用的具体方法。

相对于业务功能，应用功能更强调从技术和实现的角度进行定义，它与特定的软件或系统紧密相连。而业务能力则多从组织的业务目标和需求出发，与具体的技术实施或平台关联度较小。

以地址查询变更为例，它初步可以被视为一个业务功能。但如果我们已在资管系统中实现了该功能，那么这个地址查询变更模块则转变为应用功能，因为它现已与特定的系统紧密结合。

5、业务数据（base on what）

业务数据和业务功能、业务流程紧密相关，也属同一思维层次，没有正确和及时的数据，组织的流程、策略和价值提供都可能受到影响。因此，将业务数据纳入业务架构可以确保组织有一个统一、准确和有效的数据视角来支持其业务目标。

有人争辩业务数据应属于数据架构，的确存在这个问题，但业务架构中的业务数据和数据架构中的数据还是有差别的。

从视角看，在业务架构中，业务数据是从业务需求和业务活动的角度来看的。而在数据架构中，业务数据是从技术和实现的角度来看的。

从定位看，业务架构定义了什么样的数据是必需的，以及为什么需要这些数据。而数据架构则确定如何有效地存储、访问和管理这些数据。

如下图所示：

当然，两者也是有互补性质的，一个完善的业务策略需要可靠和高效的数据支持，而数据策略和技术实现则需要明确的业务需求和指导。简而言之，业务数据确实既属于业务架构，也属于数据架构。这两个架构的目标是确保企业可以有效地利用其数据来支持其业务目标和技术实现。

6、业务组织（who）

业务架构包含业务组织是为了明确组织内各部门和团队的职责、优化资源分配、确保战略对齐，并加强内部沟通与协作，从而有效地实现业务目标和策略，组织结构为业务架构提供了设计的范围和边界。下面示例了一个在线零售公司的业务组织。

三、业务架构的实践案例

假设一家企业计划重构企业管理信息系统，以改变分散建设导致的小系统林立，业务流转不畅等问题，下面说明其业务架构的构建过程。

1、业务策略

这里采取商业画布的形式来描述业务策略：

（1）客户细分 (Customer Segments)

• 主要部门领导及经理：他们是决策者和ERP的主要受益者。
• 员工：日常使用ERP系统，需要培训。
• IT团队：为ERP提供技术支持。

（2）价值主张 (Value Propositions)

• 系统集成：集成所有部门，确保数据的一致性。
• 提高工作效率：自动化流程，减少冗余工作。
• 准确性：确保数据的准确性和完整性。
• 实时分析：快速的报告和实时的分析，助力决策。

（3）渠道 (Channels)

• 内部培训：确保所有用户都了解如何使用系统。
• 内部网站和帮助中心：在线支持和文档。

（4）客户关系 (Customer Relationships)

• 培训和研讨会：帮助员工掌握系统。
• IT支持：快速响应任何技术问题。

（5）核心资源 (Key Resources)

• ERP软件平台。
• 培训材料和手册。
• 数据中心和IT硬件。

（6）核心活动 (Key Activities)

• ERP的选择和采购。
• 系统配置和定制。
• 员工培训。
• 持续的维护和升级。

（7）关键合作伙伴 (Key Partnerships)

• ERP供应商：提供软件支持和更新。
• IT外包团队：可能需要外部的技术支持。

（8）成本结构 (Cost Structure)

• ERP软件和硬件成本。
• 培训成本。
• IT支持和维护成本。
• 可能的升级和定制成本。

（9）效益预期 (Expected Benefits)

• ROI：长期的效益与初始和持续的投资成本之间的关系。
• 工作效率的提升百分比。
• 决策时间的减少。
• 错误率的降低。

2、价值链

企业信息管理域的价值链涉及了从战略到投资支出，到人财物，再到企业有效性相关的企业综合管理等核心业务，如下图所示：

3、业务流程

价值链的每个模块都是要依托流程来实现，流程还可以分多个层级，具体分为多少层级依赖于企业的实际需要。这里以价值链中的供应链管理流程为例说明，共分为需求预测、需求提报、采购寻源、采购执行、物流配送、采购支付和评估分析等7个活动。采购执行活动可以进一步拆分成子流程，共有20个步骤，如下所示。

4、业务功能

采购寻源是供应链管理流程的一个活动，可以认为是一个业务功能，提供包括寻源准备、寻源执行、寻源决策的功能支撑，并实现与采购进度和中标后合同启动环节的衔接等子功能，示例图如下。

采购执行是供应链管理流程的另一个活动，包括正常订单采购，目录自助采购、提前到货订单采购、采购物料管理等子功能。

5、业务数据

供应链管理涉及需求预测、需求提报、采购寻源、采购执行、物流配送、采购支付和评估分析等活动的业务数据，如下所示，这些业务数据为供应链管理的各个活动提供了必要的输入和背景信息，支持决策制定和执行，并帮助评估供应链的绩效和效率。

6、业务组织

为了更高的进行ERP集约化建设，公司新增IT指导委员会，职责如下：

四、业务架构、应用架构、数据架构、技术架构的关系

在业务架构中，业务流程被详细定义，业务流程是DA、AA和TA设计的驱动因素，这里具体以“买入股票”示范从业务流程到应用程序，又到数据实体，再到技术组件这条主线设计。

1、业务架构

1）业务流程——由买入挂单、规则检查、上报给交易所等步骤组成。
2）业务数据——买入申报指令。
3）业务事件——图中“交易所回报”事件会触发券商“处理成交结果”，当收市时，“当日收市”事件也会触发相应业务处理。可见，用好业务事件，有利于把“条件触发的业务场景”表达清楚。

2. 应用架构

应用架构师应思考：买入股票业务流程需要哪些应用服务支持呢？

1）业务流程一级的买入挂单、规则检查、上报给交易所、处理成交结果，需要IT应用服务支持，分别为挂单录入、规则检查、委托上报、接收回报、结果显示。

2）进一步地，这些IT应用服务要由具体的应用系统来实现，分别为券商App、券商集中交易系统。如下图所示。

3. 数据架构

数据架构师应思考：买入股票业务流程需要哪些数据支持呢？

1）券商的集中交易系统作为后台，首先要将委托记录排队，以备异步处理。

2）券商App不保存“投资人账户”信息，但交易后台要保存，由证券经纪业务后台做交易规则检查。

3）由证券经纪业务后台负责的交易规则检查，会用到投资人账户和投资人资产等数据信息，例如，账户余额不足时是不允许挂单成功的。

4）后台存储“回报记录”数据，也是为了异步处理。如下图所示。

4. 技术架构

技术架构师应思考：买入股票业务流程需要哪些技术组件支持呢？

1）挂单录入、结果显示等技术，由客户端应用程序支持。

2）规则检查、委托上报和接收回报是可重用的应用功能，可考虑实现成服务或微服务。

3）基础设施的技术选型，由技术架构师决定。如下图所示。

希望对你有所启示。

参考文献：

【1】温昱.业务架构•应用架构•数据架构实战.电子工业出版社,2021

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！