关于业务架构基础知识的二三事儿： 关于元模型

读者提问：我最近在对比学习 BIZBOK、TOGAF、ABAE 聚合架构、《华为数字化转型之道》中提到的业务架构要素（元模型），怕自己理解有偏差，您能否出一期解读不同业务架构元模型的文章，对比哪些元素相同、哪些不同。

感谢读者的提问，这是个不小的挑战，因为我在撰写《聚合架构：面向数字生态的构件化企业架构》一书中，自己尝试过提炼元模型，我写这本书大概用了四个多月的时间，其中光是画元模型这一项就耗时一个月左右，可以说，写这本书的时间主要花在设计元模型上，画完元模型之后的写作时间不过是在展开元模型而已。

所以，从我个人写书的经历中，就能感受到元模型的两大特点，其一，它是某种思想体系的抽象凝练；其二，它具有高度的个人化特征，哪怕是集体打造的，那也是基于一小撮人的共识。第一个特征决定了元模型是方法论学习的重要基础，同时也决定了对元模型的理解需要通过实践进行二次认识；第二个特征决定了，对元模型的统一解释有点儿像语文考试中的阅读理解，也就是说，作者本人可能未必跟我们这些学习者想的一模一样。这两个特征还决定了，学习元模型需要持续具有批判性思维，而不是奉为圭皋，无论谁对元模型做出了什么样的解读，你还是得有自己的理解才行。

接下来就简单聊一聊几个架构元模型吧，开聊之前再提醒一点，元模型其实就是某个设计方法最关注的设计元素之间的关系阐释，理解元模型抓住这点就可以。

一、BizBOK

BizBOK 是一本高度结构化的业务架构专著，几乎整本书都是用模型写的，也正是因为模型太多，所以我自己看过之后，有点儿说不准到底 BizBOK 的元模型是哪一个。先上一张它的业务架构框架图吧。

这张图应该算得上是 BizBOK 的高阶元模型了，里边包含了 BizBOK 认为的业务架构最主要的三个东西：业务架构场景、业务架构知识库、业务架构蓝图，也就是在哪用、怎么用、用了得到啥。其中，知识库里的东西，就是中间黄色底的那一大堆，可以认为是业务架构的关键知识，而里边浅黄色内圈的是核心领域，组织、能力、信息、价值流，就是谁干（组织）、对什么干以及得到什么（信息）、具备什么条件可以干（能力）以及怎么干（价值流）。任何一个企业，无论你是否重视流程管理，你都没法做到“心想事成”，只能通过一定的过程来实现目标，这就涉及到过程中的组织、能力、信息，它们通过价值流运转起来，所以，无论怎么谈流程管理，说到底，都是在研究某个特定环境下，一群人怎么干成一件事是最经济的，各类学术性、操作性的区分其实也改变不了流程的这个基本价值。

既然说元模型体现的是方法论最关注的设计元素，那也就是说组织、能力、信息、价值流就是 BizBOK 分析的核心，这里边最好理解的是组织，能力、信息、价值流的关系可能很多人会觉得绕，我觉得至少有一个逻辑上的坑要处理，也就是“能力”，其实能力不通过价值流和信息的描述是很难被具象化理解的，那么，能力就是含在价值流和信息当中的，从处理过程的角度看，没有流程就没有能力展现的时间，能力描述可能是静态的，但是能力展现绝不是静态的，没有动态过程或者说时间流动，能力无法发挥作用；从处理结果的角度看，没有信息，能力的作用就无法观察到，能力的作用要么是改变信息要么是保持信息不变，你可能觉得后半句是废话，但别忘了，我们生活在一个动态的世界，保持不变也是需要“能力”的。实际上，BizBOK 提供的能力解构方法也正是结合组织、信息、价值流分析去定义业务能力。

既然“能力”实际上含在价值流和信息当中为什么还要单独描述呢？按照 BizBOK 的解释，为了对企业能干什么达成一致的认识，减少认知上的混乱，“能力是识别需要关注的业务部门、供应商、流程、信息、技术和其他资源的关键”，我以前也讲过，各种企业架构方法论都在将自己发展为一门关于企业能力布局及能力实现的专业，这不仅限于技术侧，更多是要研究业务侧。

从 BizBOK 还可以看出，元模型是可以逐级展开的，也就是说不是只有一个最高级抽象才叫元模型，抽象度高低都可以叫元模型，每一个高阶模型的都是它低一阶模型的元模型，没错，这东西就是“套娃”，套住了很多娃。

如果想体会这一点，BizBOK、DoDAF 还有我写的聚合架构都有很明显的这个特征，当然，最好的参考还是看 BizBOK 是怎么逐级展开的，它的范围比较完整，DoDAF 主要是在数据模型上展开，聚合架构采用的是抽象度稍低的元模型设计理念。

二、TOGAF

说企业架构元模型估计谁也绕不开 TOGAF，名气大就是有好处。

TOGAF 其实有两个非常重要的元模型，就是“麦田怪圈”ADM 和内容框架元模型，分别如下：

第一个模型交代企业架构实施过程，尽管 TOGAF 自己经常强调 ADM 代表的是信息流而不是工作流，以避免自己跟“瀑布过程”走的太近，但这无法阻止大家就这么去理解 ADM。至于第二个模型就比较复杂一些了，这里边的一些名词估计就是我一开始说的那种，元模型设计者自己心里的解释可能会跟我们在学习过程中理解的稍有不同，比如说动机扩充中，也许我自己会把目标和目的的位置对调一下；我也会更愿意在角色和流程中连上一条线；这里边业务服务被定义为业务和技术之间的过渡，这显然是一个非常 IT 化的定义，但是，是不是必须的呢？

这个元模型凸显了业务架构的重要，所以，几乎是“大脑袋、小身子”的结构，技术部分几乎被压缩没了，数据、应用、技术都是以逻辑、物理的方式被简化掉了。

如果不看其他部分，业务架构这部分跟 BizBOK 的核心领域与扩展领域还是有一定共性的，尤其是核心领域中的能力和价值流，但是“信息”的位置差别还是很大的，信息在 BizBOK 中是属于业务架构的，在 TOGAF 中则属于独立的数据架构，没有明确的信息元素出现在业务架构中。至于更多的对应关系，可以看看 BizBOK 自己的解释，如下图所示。

“能力和价值流链接到功能、流程、参与者和角色，这些主题是 BIZBOK®指南中故意缺失的，因为它们代表了操作模型的视角或无关的架构视图。”对了，补充一句，尽管之前说了半天流程，BizBOK 中是没有详细流程分析的，按照五级建模的方式理解，BizBOK 只管三级活动以上的分析。

两者之间有联系很正常，毕竟大家都在研究相同的事情，也就是企业的能力布局和能力实现，都在研究怎么分析能力。之前也听人讲过，欧洲有些小的实验室挺热衷于研究元模型，还研究彼此之间模型的转化，其实元模型之间的联系和转化就跟翻译工作一样，每个元模型都是一组术语关系体系，就像语言一样，元模型之间的对接就成了翻译工作，做好了，就能把一组模型转化成另一组模型，比如 BPMN 流程模型和其它流程建模语言产生的流程模型之间能不能通过软件直接转化？这个答案就要看元模型之间的关系了。

三、聚合架构元模型

最后讲讲我自己的元模型。

这个模型就形态上来讲比较像 TOGAF 的内容框架元模型，区别在于阶段拆分和元素关系；业务架构范围的定义则跟 BizBOK 有相同理念，就是业务架构中要包含数据。不同之处在于，能力的定义在这个元模型中，是从战略实现的视角拆分下来的，从责任的角度讲，能力由岗位具有，无论是人的岗位还是机器的岗位；在实现层面，能力最终包含在业务构件中，而业务构件的定义是由业务任务、业务数据分析得到的，并且，这种结构化定义要尽可能从业务侧传导到技术侧，这就是能力实现的对称，对称是为了减少信息传递的变形和混乱，提高效率并实现企业架构的价值：对企业复杂性形成一致认知，而非两层皮的认知。

这个模型更大的不同在于取消了数据架构的独立视角，将其融入业务、应用、技术三个架构中，也就是说，工作一点儿没少，但是理解方式不再是独立视角，而是融入其它三个视角，这一点就有明显的个人化特征了，但是这种个人化也是来自于对工程实践的观察，而非单纯的想象。此外，这也涉及到方法论提炼过程中一个需要思考的地方，并非重要就必须要一个单独视角，也并非没有单独视角就不重要。

企业架构方法论也是代表“世界观”的，不过这里别把“世界观”想象成附带各种价值色彩的东西，这里的“世界观”指的就是观察世界的角度和基于这个角度的观察结论，所以，每种架构方法论都是认识设计对象的观察方法，架构制品就是观察结果，有几个视角取决于观察的需要，该有几个视角并非一成不变的，分分合合，认识而已。

更多阅读：

关于业务架构基础知识的二三事儿： 业务能力