The Open Group的业务架构概念主要来自于BIZBOK。BIZBOK认为业务架构包含4个核心要素：价值流、业务能力、业务信息、组织。其中，业务能力描述功能（how），价值流描述利益相关者（who）和价值关注点（why），业务信息描述数据（what），组织则描述业务分布（where）。这些要素分别从what/how/who/where/why等角度描述业务，但都是在概念层进行描述；而流程则是在逻辑层描述业务是如何运作的。概念层只说做什么，逻辑层回答怎么做，因此业务架构中的价值流、业务能力都可以跟流程进行映射。

TOGAF元模型中，价值流、业务能力与流程之间的关系被定义为Operationalize，即：

• 价值流在运作层面被流程实现，流程在运作层面实现价值流；

• 业务能力在运作层面被流程实现，流程在运作层面实现业务能力。

到此为止，我们可以得出如下几个简单结论：

• 业务架构从不同维度描述业务，包含多个要素，如：业务能力、价值流、业务信息、组织等，无论如何给它们命名，这些要素本质上就是在概念层面描述企业的What、How、Where、Who、Why；
  
• 流程是业务架构中的一个要素，它在逻辑层面描述业务，价值流、业务能力等概念层面的要素都要落实到流程上，通过流程描述它们在运作层面是如何实现的；
• 流程架构，或者说流程分类框架，是对企业中大量的实例化“流程”进行分类的框架，它一方面有助于回答流程“全不全”的问题，另一方面也有助于落实流程的管理责任。

如果引入业务架构是为了“向下看”，优化流程架构，压实流程管理责任，流程架构仍然是企业落实管理责任的重要依据，那不妨把业务架构作为流程架构设计“背后”的方法。结合企业自身的治理结构，可以将价值流、价值流阶段作为流程架构，也可以把L1-L2的业务能力作为流程架构，甚至可以部分用价值流、部分用业务能力作为流程架构，只要能够跟企业的治理结构相匹配，有助于落实流程管理责任，都是合理的。

如果引入业务架构的目的是为“向后看”，设计或优化应用架构，指导IT规划，就应该把业务架构回归“在概念层描述业务”的定位，特别是当应用架构采用组件化、服务化的设计思路时，业务架构应该聚焦识别业务中共性、稳定、标准的构建块，才能为应用架构的设计提供输入，支持更为精益、稳定和敏捷的IT架构设计。这时业务架构跟流程架构的定位是不同的，业务架构本质上是从IT视角对业务进行抽象而产生的业务参考模型，并不服务于业务管理提升、流程优化等目的，此时不建议将业务架构中的术语与流程架构等同。