对企业架构中的业务架构关键点的进一步说明

因为最近在重新规整企业架构方面的资料和文章，特别是企业架构中的业务架构部分，因此今天想重点对业务架构的一些关键点进行说明。

注：这篇文章仅仅作为关键点的记录，不作为体系化介绍业务架构的文章。如果希望了解完整的企业架构和业务架构情况参考EA和TOGAF相关资料。

完整的企业架构

对于EA企业架构各种定义相当多，但是不论哪种定义都可以看到会对企业的战略，组织，业务，应用，技术，管控治理各个方面进行完整的结构化描述。

不论哪种定义都需要看到，企业架构包括了业务架构+IT架构。对于TOGAF整体架构框架里面IT架构本身又包括了数据架构，应用架构和技术架构三大部分的内容。

简单总结企业架构就是对企业业务和IT能力的结构化描述，重点要回答两个层面的问题。其一是业务如何支撑企业战略，其二是IT应用如何支撑业务目标实现。

业务驱动IT，最终业务和IT又是高度融合在一起的，有效支撑企业战略和业务实现。

什么是业务架构

我们TOGAF里面的这张图

从这张图你可以看到业务架构包括了业务战略动机，业务组织治理，业务能力行为三个方面的内容。TOGAF对业务架构的粗略定义如下：

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

而我个人对业务架构核心的定义如下：

企业的业务架构应该是为了实现企业的业务战略目标，对企业的业务能力进行的结构化聚合描述。这个描述即通过业务域，子域的划分来体现了业务能力的上下文边界；同时又描述了业务域之间的相互关系和业务协同。

注意在这个定义里面没有谈到业务流程，而是强调了企业的业务能力结构化呈现。也就是说企业架构的核心是你应该如何规划你的业务能力，并进行结构化聚合来支撑企业当前的业务战略目标。

当然，对于业务架构阶段的输出工件有很多，对于常说的业务流程图，业务能力，业务交互矩阵，组织结构图，业务用例分析图，价值流目录等都是输出工件。如下图：

当时我仍然想强调里面最核心的仍然是业务能力图。

对于业务能力图的构建，当前主要两种方式， 一种是完全参考IBM的CBM组件化业务模型的方式来构建业务能力图，如下图：

这种方式类似矩阵构图，既要体现价值链，又要体现横向的执行-管理-决策的分层。还有一种方式就是弱化横向分层的业务能力架构图，参考如下：

不论哪种方式都可以看到，业务能力图都需要有明确的业务域，业务子域划分边界，有对核心的业务能力的定义。所以你会感觉该图和软件开发里面的应用功能架构图有点类似。

业务能力是啥？

再次回到业务能力这个词，业务能力本质和SOA里面经常谈到的Service服务是一个概念。业务能力就是一个业务域或者一个业务单元，你能够对外提供的有价值的服务。

业务能力的重点是你应该提供什么样的价值输出，而非你如何通过相应的人，流程配合来达成这个输出。所以业务能力强调的是上下文边界，强调的是能力接口的开放，强调的是粗粒度。

业务能力是结果导向视角，而非过程导向视角。即你内部通过什么样的流程实现这个能力我先不管，我重点是搞清楚为了支撑业务战略目标，我需要具备什么样的能力。

一个企业的战略实现就是由多个业务能力来支撑的。

这些业务能力如何支撑业务战略？

这本质就是企业核心的业务价值链图。类似波特的价值链模型，供应链的Scor模型，产品研发的IPD模型，都可以理解为核心的顶层价值流或价值链。

业务能力图如何构建？

注意，以下是我最早的业务能力图构建的思路。

即基于价值链模型，对企业端到端的业务流程进行分析，逐步展开到2级，3级，乃至最底层的EPC事件链流程图。在流程分析完成后就能够找到关键的业务活动。有了业务活动后将这些业务活动按高内聚，松耦合的原则向上进行抽象和聚合，形成业务能力图。

这个是我最早业务架构的构建思路。

当前我对该业务架构的形成思路进行重新梳理和调整。

即业务能力图的构建核心步骤如下：

第一步给出顶层价值链图。

这个图实际即体现了功能结构图概念，又通过阶段体现了高级流程图的概念。可以看出是静态结构图+动态高阶流程图的一种融合。

第二步之间既有顶层价值链图进行能力分解。

注意这里不再是通过详细的端到端流程分析，找到业务活动后再朝上聚合。而是直接对顶层价值链进行业务能力分解。比如对于顶层已经有供应链管理，我们直接朝下分解为招投标管理，采购管理，库存管理，供应商管理等业务能力。

所以这个分解不是谁都能做的。

你必须要熟悉当前的行业，业务的标准参考模型，当前企业的业务，你才能够快速将大的业务能力分解为小的业务能力单元。

为什么不通过流程分析来做这个事情？我在前面已经强调过了，业务能力图构建重点是回答我需要什么样的业务能力支撑业务战略，即分析重点是结果导向的，而非过程导向的。首先要识别我要什么能力，其次才回答如何通过流程形成这个能力。

我需要有供应商管理这个能力。

但是我一开始并不需要马上去详细分析供应商寻找，供应商申请认证的具体流程。

第三步能力分解到下层后对接到流程建模

当业务能力分解到4到5层的时候，这个时候你会分解到供应商新增，供应商变更等业务能力。而这些业务能力本身就是一个完整的业务流程。

因此这个时候你可以进行详细的流程分析，具体分析供应商新增流程应该如何做，涉及到哪些业务部门，业务角色，具体产出哪些业务单据和业务数据等。

所以这个时候你可以通过EPC流程图进行最详细的描述。

第四步业务能力能否支撑端到端业务进行复盘验证

在业务架构的输出工件里面有大量的业务交互矩阵，包括了业务和功能，业务和数据，业务和流程，业务和组织等。所有的交互矩阵本质就是在补充业务能力图在架构上描述的不足。

前面谈到的业务架构既清楚说明业务能力和价值提供，又同时要说清楚业务能力之间的集成关系，那么集成关系可以通过交互矩阵来进一步说明。

注意在前面的业务能力图构建中，我们更多是快速地描述清楚要做什么，需要具备哪些能力的问题。但是没有去描述如何做到的问题。

当业务架构核心能力都梳理清楚后，我们需要进一步去描述当前的业务能力如何支撑企业核心业务价值链和端到端流程。因此我们需要进一步去构建端到端业务交互流程图对该点进行验证和复盘。类似如下图：

通过这种图，我们将分解后的业务能力和端到端流程进行融合。进一步回答业务能力如何支撑端到端的流程。业务能力应该如何去组合和编排业务流程。

这个本身又回到典型的SOA参考架构思想。

好了，大家可以思考下为何业务架构中梳理到最底层的EPC流程图或进行详细的业务建模仍然是必须要做的事情？