好多朋友都在讨论“业务架构”，较多的会引申到与IT架构的关系，但笔者沟通过很多朋友，真正能说的清楚的为数不多，也较难达成统一，尤其是业务架构，不同领域不同职业都有不同的理解。笔者也借助此篇文，结合过往项目经验，分享对业务架构的理解和组成业务架构的关键要素。

一、企业战略分解

企业开展工作，必须依托于企业战略。战略作为业务架构的重要环节，要求设计者对企业战略的理解很高，所以为什么企业花大价钱招聘有经验的COO、CSO或者CIO，设计出的业务架构与战略目标不匹配无法扩展延伸，其原因也是对企业战略目标还不够清晰，进行业务布局时出现了漏项或多余项，造成资源浪费。

笔者认为，所有的战略都必须量化后。举个例子，HN控股提出的“一基两翼”：即以清洁能源发电板块为基础，以太阳能光伏研发与生产为左翼，以太阳能光伏应用为右翼的产业结构，目标明确便于量化。那如果是“让全世界都使用清洁能源”呢？那就应与数据进行诠释，可以分解为，“清洁能源的使用占世界能源使用量的百分之百”这不是文字游戏，这是需要用数据说话的，如果没有实现百分之百的占有量，就说明战略未达成。无论企业规模大小，战略必须量化，成为可分解可执行的工作目标。

在企业战略设计中远景、使命与目标被誉为战略三大核心要素，是战略设计的“顶层设计”，及其重要，为避免“上梁不正下梁歪”，设计者必须与企业管理者与参与者进行充分的沟通。许多技术人忽略了战略，认为战略与技术开发无关，这种想法大错特错。作为三要素支撑的便是企业将要采取的行动，绝大多数企业行动都是围绕着客户开展的，比如渠道管理、客户信息管理、客户关系管理、合伙人管理，财务管理、绩效考核等等。

二、价值链分析

企业在分析竞争力时通常会采用价值链分析，主要强调单个企业的竞争优势，后来演变成现在咨询公司常用的价值体系。如果说业务架构纵向分析依据是企业战略分析，那么横向分析就依托于价值链分析。

价值链主要包括了基本活动与支持活动，基本活动是指保证企业正常运行的生产过程，支持活动是指对基本活动起到辅助作用维持企业基本运转的各类活动，在企业中会有业务部门与职能部门之分就是遵循了价值链的基本规律。为什么要在设计业务架构中进行价值链分析呢？主要目的是描述企业价值创造的过程，为审视自身的业务能力提供分析模型。所以在企业中价值链设计是完全动态开放的，只要符合企业特点，满足市场需求，覆盖其价值创造过程即可。

三、对标与分析

对标的好处就是快速学习，效仿提炼行业最佳实践为我所用，对标也是企业工作中最常应用的手段。很多企业邀请咨询公司全权委托其进行业对标分析，交付清晰，逻辑缜密。问题是很难将企业管理问题与成功要素相互结合，因为咨询公司在短时间了解到的可能只有表象。这些突出的表象是如何形成的，其引申出的真正含义是什么很少有人能说的清，包括企业内部员工，就算了解相信也是自己负责的业务条线，能够描述企业业务全景的人少之又少。所以在这种情况下，去对标最佳实践，提炼成功亚欧为我所用。8年前华为邀请IBM GBS去做管理咨询，笔者有幸做过现场支持，华为的员工真是虚心，老板要求对IBM的交付成果不许有任何质疑，先运行企业，在运行中找问题，再优化，笔者认为这才是渗透到骨子里的对标。

对标的目的是快速提取成功要素，并将这些要素合理的分配到价值链的业务领域上，业务领域的划分取决于企业的战略布局与价值定位，明确为哪些客户提供什么样的服务或产品，比如房地产行业为客户提供住宅、公寓、写字楼、商业综合体等资产买卖与配套服务，这就产生了投资拓展、规划设计、工程施工等各种具体的业务，同时为了支撑这些业务，企业又会配套人力、财务等职能体系。如果管理者认为这样的颗粒度不够，再细分消费领域，也会将客户进行分门别类，比如刚需客户与改善型高端客户，那产品线就会优化调整，业务布局与职能也会同时调整。 业务领域一般围绕客户与产品两个维度，选择哪种维度需要根据外部市场、企业特点与经营内容而定。

业务领域分析完成将进行业务流程的分析，业务流程分析是将一个业务领域中过的多个业务过程，按照价值链约定范围合理分解，形成每一个价值链中一个或者多个作业指导步骤。这里提一个注意事项，企业内部需采用一套标准的流程设计语法，否则很难进行流程与流程、活动与活动之间的衔接。

四、数据建模与分析

业务领域与流程分析是一个漫长而细致的过程，需要不断的摸索、分析、对比总结，这是建模的过程，所以模型的质量完全依赖建模人员的经验与能力。流程模型用于分析业务行为，数据模型用于分析数据，企业级的IT设计就是将这两个模型进行融合。数据建模，从IT角度来说，就是建立实体关系图，也是建立数据库的设计基础。它是按照业务对象的划分的，将数据属性按照实体进行具象，并表述实体之间的钩稽关系，以此来指导技术人员开展系统与数据库的设计工作。

实体关系图一般面向单个系统，如果构建企业级的数据模型，就需要横向分析所有的业务领域的实体关系图，所以我们需要以一个规划者的思维，整体考虑建立分析架构。记得IBM有一套数据模型 FInancial Services Data Model ，囊括了金融行业80%以上的数据业务，其数据类型分为九类，如下。该模型的优点就是将数据实体与数据属性进行归类，形成统一的逻辑模型。

生产过程中要通过管理平台对数据字典进行严格管控，未进入数据字典的数据项无法成为数据ID，当然也不会被使用。虽然这种办法有点死板，但却是很有效果。企业级的数据模型是要对业务数据进行全面建模，对生产进行严格管理，同时对历史数据进行处理的过程。

五、组件分析：

从技术角度理解，流程建模表达的是“处理”，数据建模表达的就是“输入”与“输出”。通过数据建模与流程建模的组合，可清晰的描述活动的输入和输出有哪些，流程的处理规则是什么等等。我们更进一步的与IT技术相结合，实现业务活动系统逻辑是在什么样的场景（时间）下开始执行的，该逻辑程序需要读取那些数据（实体），依据什么样的顺序（活动），规则（任务），由谁（组织与角色）执行，结果会是哪些数据（实体）。任务会直接处理数据，而这类操作就是我们熟悉的增，删，改，查。

一个业务领域是有一组活动构成的，而这些活动又是分布在价值链的不同环节中。对于业务复杂的大型企业，组件的内聚性一般都不好，所以需要进行更精细的划分来明确各组件之间的关系。在系统设计上，我们会将相邻的数据实体聚合在一起，遵循行为接近数据的原则，再将相应的功能组合成一个组件。现阶段超火的“中台”逻辑，也是根据提炼与拆分业务与技术组件作为实现基础的。笔者在GBS工作时，因为项目需要，研究了IBM 的CBM“组件化商业模式”（Component Business Model,CBM），它对组件的划分很具有参考意义，有兴趣的朋友可以去研究研究。

综上所述，业务架构的设计包含了企业战略分解、价值链、业务领域、业务流程、数据分析与组件分析等重要元素。

• 战略分解代表了业务架构的总纲领，是业务架构的顶层设计，后续的价值链、业务领域及流程等步骤的趋向，全部由战略分解而定。

  
  

• 价值链代表了企业能力统一的“横向架构”，每一个价值链中包含了多个业务活动，业务领域代表了构建企业统一能力的“纵向架构”，表述了业务流程如何贯穿业务领域而实现企业目标。
  

  
  

• 业务流程也是业务架构中的业务活动，由不同的角色分别完成若干的任务组成，在执行过程中必然会与业务数据发生关联。

  
  

• 业务组件中业务能力通过任务与活动进行关联活动与领域的关系，表达对业务领域的支持。

以上就笔者总结的企业架构的整体逻辑，画了张图以示各要素的位置与关系，供各位参考。

下面我们在说说业务架构与IT架构的关系，要说这个话题，不得不先说说TOGAF，TOGAF模型率先提出企业架构分为两部分，业务架构与IT架构，绝大部分企业架构由IT架构发展而来，笔者提出通过信息化手段反推管理能力提升，其实也是基于TOGAF模型推导而来。业务架构是将企业战略目标分解为行动策略并转化成工作方式与步骤，其内容应包括制度、流程、组织、经营模式等。当然后续的诸多模型中也出现了关于业务架构与IT架构的定义，在这里就不一一阐述，可翻阅相关资料。

TOGAF提出，业务架构应属于IT战略部分。但笔者认为，业务架构更趋向企业级的业务能力表现与管理者的经营决心，偏向业务合理性与连贯性。所以业务架构并不属于IT战略，两者相对独立。业务架构应更多的面向业务人员与企业管理者，而IT架构应该做好对业务架构的重构与承接。业务架构应以企业战略为视角，以目标为导向，按照业务职能与业务过程逐一分解，再与业务能力匹配，形成具有支持企业战略实现的能力布局，我们可以将这个布局理解成为“业务架构”。业务架构应是灵活的，应以更集中的能力实现多变的业务需求，笔者理解现在的“中台”战略实际上也是一种业务结构的设计类型。

业务架构好比“肉体”，IT架构好比“血液”，血液永远依照肉体的先天脉络布局而流淌。10年前刚接触IT时，当时分为两类应用架构与技术架构，而今随着数据应用的日益频繁，数据架构与数据安全架构也列为了企业IT架构的重要组成部分。

• 应用架构：关注功能布局与业务布局的匹配性，是业务结构的直接“诠释者”。

  
  

• 技术架构：关注分层结构，一个逻辑分层很可能要通过多平台才能实现，因此在分层中还要加入平台规划。
  

  
  

• 数据架构：数据的重要组成部分是数据模型，数据模型与业务架构关系比较紧密，甚至是业务架构的组成部分。

  
  

• 安全架构：现阶段企业安全架构不再是网络或者信息安全，需更贴近企业业务架构，更符合企业战略的要求。
  

所以IT架构中，应用架构与数据架构与业务架构关系最为紧密。作为中大型企业，最理想的状态便是由专业的应用、技术、数据与安全架构负责人。如果没有条件，建议：应用架构与业务架构可以合并，毕竟业务能力清晰后再向部署延伸便是应用架构。