关于业务架构基础知识的二三事儿：业务架构与业务流程

我自己出来讲业务架构到现在也算三年多了，我经常说自己是个烧冷炕的，那时候几乎没多少人在公开讲这个领域，因为虽然有大名鼎鼎的 Zachman 框架、TOGAF 等方法论可供大家学习，但是国内企业实打实且从头到尾完整实施的案例极少。华为早在 2008 年就成立了企业架构部，但是出来讲企业架构也不过是这几年的事情，尤其是 2022 年《华为数字化转型之道》这本书出来之后，毕竟企业架构同道少，所以，2021 年和 2022 年我也都去华为交流学习过，其实所有落地的方法论都有些区别，这是需要注意灵活的地方。

由于充分的实践很少，所以大家谈论企业架构时更多是在对着方法论基于自己以往的工程经验进行理论“猜测”式的探讨，这么说没有批评的意思，毕竟很多讨论这方面的文章都没有关于上述方法论的实施体感，而只有理论层面的解释、比对，这么讨论虽然有助于大家加深理解，但是对于如何落地实施，并没有更深一步的指导作用，在一些基础知识方面也是众说纷纭，如同 Zachman 老先生在上个世纪 80 年代末写文章说的那样，他认为当时对“架构”一词的使用过于宽泛，内涵差异太大，以致于“架构”一词已经失去了意义。

其实我自己做实战型业务架构工作坊的时候也经常犯这方面的问题，因为自己接触的时间久了，就会不自觉地认为有些东西不用解释，当然，这个行当很多名词没有权威定义也是事实，所以，习惯了“自觉”去做，但是这样对听课的人来讲有些“不公平”，所以，有些概念，就算不能精确定义，也该从我自己的视角讨论下，跟大家共同切磋。我自己写了企业级业务架构领域的第一本中文书，当时还不得不为业务架构下个定义；又推动了第一个工信部教考中心通过的业务架构技术能力证书，录制了体系化的视频课；我也还致力于推动更大的业务架构师联盟类组织的建设，所以，在基础知识方面也不能过于“实用主义”，有些“形而上”的东西该聊还是得聊。

不过聊之前还是要强调下，我对业务架构的态度是非常纯粹的，这就是一个业务和技术之间快速沟通的“统一语言”，因此，我不追求任何精妙的方法，就像你正常沟通时不会把普通话讲成文采飞扬的诗歌散文一样，务求双方都懂、都会、都能讲，所以我也才会把业务架构初级课程定位在让业务人员也可以学，也应该学的位置上，就是希望能在企业建立起结构化思维的“语言环境”，使结构化思维能够进一步普及，这是所有从业者的数字化转型，也只有这样，真正要去做解决方案的业务架构师们才能顺利开展工作，而不是去做个“夹心饼干”。

好，那要讨论哪些基础概念呢？我想到哪说到哪，一篇文章写不全，咱就再写第二篇，上不封顶，但至少一篇保底。

第一个基础知识，我想，还是先说说业务架构，或者说我心目中的业务架构与之前的方法论说的不同之处。我常讲的业务架构不仅是从业务视角描述企业，像 TOGAF 说的，战略、组织、关键流程等等，按照我们的工程经验，这是一个面向业务能力布局的结构化分析方法，可以参考我在《企业级业务架构设计：方法论与实践》和《聚合架构：面向数字生态的构件化企业架构》中的定义，这个所谓的面向业务能力的布局与我们常讲的应用功能布局有什么区别呢？这个确实在课堂实践中有学员困惑过，因为当时技术同学自己先试着画了个业务架构图，然后发现跟自己画的应用功能结构图高度相似，其实原因很简单，就是画图时潜意识里都是功能视角。

那业务架构的视角到底是什么？是对业务能力的定义，也就是说，这时还没走到功能划分，设计者脑子里要想的是，如果你是一个业务部门的领导，你的业务分工要如何设计最合理，而不是直接跳到有什么功能上。但是这与一般意义上的业务领导给下属派活儿又有些差别，传统意义上的派活儿是从“事情”入手的，什么事情分给谁干，而业务架构的业务能力定义是从数据入手，或者用业务更好懂点儿的词——信息——入手的，把哪一类信息交给什么人处理，这就是关于业务能力的一个即可以被业务稍微绕个弯理解，也能符合技术视角的定义。数字化时代，对企业而言，组织结构设计也可以看成是为了处理某类信息而聚类了一群人，这群人再用一个特定的过程处理这些信息，这就是部门和团队的设计基础，处理人事信息的、处理财务信息的、处理产品设计信息的、处理售后服务信息的、处理客户关系信息的，这样理解组织结构可以更好地适应康威定律，见下图：

以信息聚类行为和角色，这是数字组织的设计基础，也是业务能力定义的基础，在这个基础上再分析才是功能、用例、服务的定义。以往的业务分析有些是纯流程的，有些是纯数据的，有些是二者有点儿关联的，但一直还没有这样深度关联的，比如原有的 CBM 也只是从流程角度看业务组件，但是我们之前设计时，业务组件里是希望只有离散的任务而没有连续的活动，这个不在这里展开讨论了。也就是说，直到我们在工程实践中深度地试了一次，才真的理解了或者自己解释了这些概念的区别，当然，不要误会，我们不是用这个方式重新设计了企业的组织结构，而只是用这个方式进行了业务能力定义。解释清楚了吗？不清楚也不要紧，业务架构好就好在不做你是很难真有实感的，以后我们还可以慢慢聊，尤其是你接触到相关实践的时候。

第二个基础知识，我想，再说说业务流程。梳理业务架构一定少不了梳理业务流程，而且，也有读者问有没有流程架构？流程架构跟业务架构是什么关系？我不敢说没有流程架构，毕竟我从来不觉得自己在业务架构方面有什么资格肯定这个、否定那个，而且我对方法论的态度非常务实，我从来不赞成在方法论方面花太多时间在 PK 上，还是借鉴好的经验吸收到自己身上才是“聪明”的，讨论架构要开放，不要搞什么卫道士的思想，更不要上纲上线去讨论什么莫须有的东西。架构这个词的核心内容就是结构、关系、原则，这个倒是有国际定义的。这么套的话，有个流程架构也不稀奇，流程的结构、流程的关系、流程的设计和演进原则，这么说起来也不违和。

那么如果可以有，它跟业务架构什么关系呢？这个我可以放开点儿胆子论论了，首先，它是业务架构的一部分，毕竟都得梳理流程，如果一个企业即搞流程治理又搞业务架构，那你心里一定不希望由此出现两套流程结构，那基本上是在浪费时间、浪费金钱、浪费生命，所以，我们建议“同源框架”，哪怕你再搞风险管理、合规管理、体验管理，也不要一处一套流程，那会折腾死人的。既然流程架构可以和业务架构共用一套流程描述，那就有个“主数据”和“主方法”的问题，以谁为主，我是搞业务架构的，当然会说以业务架构为主，但实际上也是该这样做，因为业务架构是可以关联 IT 实现的，如果不以它为主，那反倒在其他用途上产生 IT 需求时会引起麻烦了。

如果以它为主，方法上有什么要求呢？梳理流程的方法很多，我无意搞方法上的 PK，首先要做的是企业内部统一流程梳理方法，不要一个部门一个样儿，此外，如果考虑到与 IT 对接的视角来讲，在各种流程梳理方法中我还是建议采用 BPMN 的方式，因为这个流程建模语法在控制任务颗粒度、控制流程图展示复杂性方面还是有优势的。做业务架构虽然不以做 IT 架构为首要目标，但是必然会关联到 IT 实现上，所以这方面要有所顾忌，如果真的希望业务架构设计可以更好地驱动技术设计，那必须在流程结构颗粒度及与数据实体的关联上下功夫，这一点大多数流程梳理方法是没太考虑过的，因为对单纯的流程管理来讲也不需要特殊强调这种视角，尤其是与数据实体的联接上，这是多少有些偏向设计了，也正是因为这样，采用业务架构方式梳理的流程必须要与技术有良好的对接，而这一点，多数的流程模型方法面向的是流程管理而非系统规划，所以只能供系统分析人员做“参考”，而无法“驱动”，随着传统开发模式受到越来越多的来自新技术、新思维的冲击，业务已经不能再只是解释需求了，需要更多地结构化自己，更深入、更多样地参与到开发中，而这么做的起点其实正是对业务架构的梳理。

延伸阅读：

老司机跟你聊聊学习企业架构和业务架构的那些事儿