企业级业务架构如何设计？

对于企业级业务机构设计而言，一定是从企业管理、战略、组织结构上来入手，这样才能更好的驱动企业数字化转型和信息化建设。

以前，我们的科技都来自于业务，有了实际的需求，迫使科技的进步。业务提需求，技术管实现，业务发展催生技术发展。但现在，科技的进步速度远远超出了我们的业务发展速度，我们的业务在技术的引领下，发展得更多种多样，商业模式也受到影响，技术与业务已经到了深度融合得时代。

科技的快速发展驱动着每一个行业，每一次科技的革命都会诞生一批伟大的企业。但传统的企业在科技的浪潮中如何能保持竞争优势，相信每个企业主都知道调整战略方向，顺势而为。

那么这个“势”到底是什么呢？

我们从工业革命开始，社会飞速发展，从设施化时代进入自动化时代，现在已经处于信息时代，往数字时代，智能化过渡，企业的信息化转型显得至关重要。那在信息化建设中，应该怎样搭建业务架构，与技术架构又有怎么样的关系？

一、什么是业务架构

业务架构是以企业战略为基石，结合业务流程，组织架构的一种表达方式。是技术架构的驱动力，企业通过构建业务架构，来缓解企业压力，与转型的不适。

作为企业业务与技术的的桥梁，实现信息化的深度融合。不同于业务流程和业务需求的分析，业务架构更强调整体性，结构性。技术永远都是为业务服务的，所有的架构师都是为了解决某种业务而诞生的。能解决实际的问题，才是技术的价值。

二、业务架构与技术架构的关系

1）业务架构的作用

多数的架构师和业务，和企业发展战略上是脱节的。他们专注于技术的实现，而忽略使用这项技术的业务目的，与企业的联系。业务架构的作用就是在这之间建立桥梁，用于实现业务需求到IT的顺利传导，将战略映射到技术上来提现。

在通向“数字化”时代的进程中，业务架构的独特性在于帮助企业完成了深刻的“数字化”转型，使企业通过信息技术将内部、业务与IT深刻地连接起来，成为高效的“数字化”企业。

2）业务架构带动深度融合

如果业务本身不结构化，直接用技术架构一位的去迎合，去套。那么技术人员也很难做出一个具有良好架构的系统，业务架构就像一个容器，而业务架构就是里面的内容。

三、业务架构设计

业务架构搭建，要从顶层结构即企业战略开始，通过梳理企业目标，发掘企业能力需求（既可能是企业自身业务与技术水平发展产生的转型需求，也可能是科技导致的行业生态变化、来自竞争对手的被动需求）。再通过价值链分析方式，构建企业整体能力布局（即业务架构），并在分析过程中，将能力需求放入能力布局中，并以此在业务层面落地战略、检验战略的可行性，甚至调整战略。

1）价值链分析

价值链分析模型就是企业竞争力分析，这个方法从企业管理的角度来说，是久经考验的方法，特别适合用来做企业级横向的竞争力分析。价值链主要包括基本活动和支持性活动，基本活动是指主要生产过程，支持企业上下游的核心流程，支持性活动则是指对基本活动起辅助作用及维持企业基本运转的各类活动。

这里我用一个生产制造业的价值链举个例子，对于不同的企业，性质不同，则价值链不同。价值链如何设计完全可以是个性化的，只要确认能够符合企业的特点，覆盖其价值创造过程即可。

抽象出价值链模型

2）流程模型分析

划分工作流：搭建好价值链这一“横轴”之后，就可以基于价值链的各个环节分析多个“竖轴”了。数轴就是价值链上业务领域的划分取决于企业的战略和价值定位，从客户和产品出发，业务领域实际上就是由一组业务活动构成的，业务活动中的角色和任务，体现了所有参与到价值创造过程中的组织单元的分工协作关系。分析工作流：工作流程的分析实际上是将一个业务领域中的所有业务处理过程按照价值链约定的范围进行分解，形成每一个价值链环节中的一个或者多个工作流，通过UML等工具进行企业业务流梳理。3）企业数据流分析

说到数据模型，我们肯定第一反应是想到数据库设计中的ER图，但是ER图（实体关系）通常是面向单个系统进行构建的，用来描述实体,属性,任务之间的关系。

在构建企业级数据模型时，就需要横向分析所有业务领域的ER图，通过建立分析框架，根据实体、数据属性进行归类，形成统一的企业级逻辑模型，保证数据的唯一性。

对于不同行业，由于业务的特殊性，如：自动化包装业务、信息采集业务。需要不同领域的专业信息系统来完成，企业级的业务数据通常会随业务在各个业务领域流动，这就要考虑将每个业务领域的ER模型结合一起设计，涉及到系统集成。

4）组件分析：流程与数据的结合的产物

流程模型与数据模型是描述业务的一对“难兄难弟”，流程模型表达的是“处理”，数据模型表达的是“输入”和“输出”，合起来就是计算机的基本工作流，这在大部分软件设计方法论中都是共识。

数据模型和流程模型的组合，可以清楚地描述出，什么样的事件或条件可以触发一组业务活动，业务活动需要的输入有哪些，业务流程的处理规则是什么，经过业务流程的处理，输出又有哪些如果将该业务系统化，就会变成如下的问题：

实现业务活动的计算机程序是在什么样的场景（事件）下开始执行的？程序需要读取哪些数据（实体）？依据什么样的顺序（活动）？规则（任务）由谁（组织、角色）执行？执行之后将会产生哪些数据（实体）？任务会直接处理数据，而这种处理通常可分为增加、修改、删除、查询四类操作。在软件设计上，通常会考虑将关系较近的数据实体聚合在一起，按照行为接近数据的原则，再将相应的功能聚合成一个组件。从业务模型的角度来看，就是按照主题域划分边界，将与主题域内实体相关的任务聚在一起构成业务组件任务与实体的关联主要是基于对实体的增、删、改操作。

数据模型包含主题域这个层级，即将关系较近的数据实体聚合成一个分类，对于这种关系我们可以给出一个主题名称。在软件设计上，通常会考虑将关系较近的数据实体聚合在一起，按照行为接近数据的原则，再将相应的功能聚合成一个组件。从业务模型的角度来看，就是按照主题域划分边界，将与主题域内实体相关的任务聚在一起构成业务组件。

下面是笔者在设计某信息系统时，结合数据模型以及主题域划分边界，构建的组件化设计思路。