关于业务架构基础知识的二三事儿（编号：009 从业务架构与其他架构的关系看数字化程度）

最近非常高兴地看到关于企业架构、业务架构的文章越来越多，大家的重视程度、活跃程度都上升了，笔者以前常说自己是个烧冷炕的，企架和业架，做的企业少，做得深的更少，所以文章不算多，又常浮于表面，理论有余、实务不足，现在有所改观，但总体上还是基于过去不完整实践的理解多，深入实践的少，尝试总结升华、不断探索的更少，如同本文的标题，这其实也反映了对基础知识的共识依然不足。笔者也愿意继续循着这个系列写下去，也欢迎大家提供问题线索。

好，来到本期，最近也看到一些讲业务架构设计方法的文章，其中关于战略与业务架构、业务架构与其他架构关系的理解有些过于“直接”了，也过于IT化了，笔者正好借着这个缘由，谈谈自己的理解，供大家思考。咱们先从企业架构中各个架构的关系讲起，再扩展到其他部分。

• 一、企业架构中各个架构的关系
• 一图胜千言，扔个图先：

一般总会觉得企业架构主要就是4个“A”，先分析业务架构，再分析数据架构、应用架构，最后是技术架构，数据架构和应用架构都被认为是属于IT的部分，也合称“信息系统架构”，但是实际上，从企业的视角看，企业架构是为了实现企业战略，也可以做到分析完整的企业，业务架构也并不单纯指向系统实现，笔者也曾强调，不建议“业务功能”这个词出现在业务架构部分，这是太过IT化地看待业务架构，业务架构本身是对业务的结构化分析，侧重通过流程和数据以及组织关系等因素全局性、结构化地分析企业的业务，可以单纯用于业务管理、业务分析，因此，完整的业务架构可以包含企业所有业务，既包括线上也包括线下，是企业业务的完整视图，换言之，业务架构包含的业务内容可以大于甚至远大于应用架构包含的业务功能，二者差别越小，业务的数字化程度就越高。

笔者也认为数据架构中相当一部分内容都属于业务架构（笔者在《聚合架构》一书中干脆将业务架构和数据架构合二为一了），或者说可以在业务架构分析中完成，尤其是企业级逻辑数据模型，但是大多数企业的业务并没有被完全“数据化”，也就是，业务架构中依然有很多没有数据留存的业务内容，甚至线下数据也没有，所以，业务架构中的内容一般没有被完全“数据化”，二者差别越小，业务的“数据化”程度就越高。

数据架构和应用架构也没有完全重叠，这里区别主要是线下数据留存的业务，二者差别越小，数据的线上化程度就越高。

应用架构会有一部分和具体业务无关，属于支持性功能，也即常说的业务可以不太操心的部分；这部分可能有属于数据架构关注的数据，也可能有不太重要，大家都不太关注，甚至数据架构都没去管的数据；技术架构也会有一部分大于应用架构的内容，主要是基础设施建设，这部分就是业务更难触及到的“纯技术”内容了。

如果企业架构做得很完整，那么，企业架构统合起来就是数字企业的完整视图，这里既包括了业务的数据和非数据部分、线上和线下部分，也包括了一个企业的业务部分和纯技术部分，看到这个图，读者就很容易猜到通过4个架构的关系怎么看企业业务的数据化程度、数字化程度了，数据化刚才说到了，数字化自然就是四个架构重合度最高的部分，因为数字化必然落到应用上，应用必然映射到技术架构上，所以，这是四个架构重合度最高的部分，这部分占业务的比重越大，业务的数字化程度就越高。数字化程度是不是一定代表成熟度，这倒未必，还得衡量稳定性、扩展性等其他因素，这里看到的只是程度。

由此，笔者也常强调一点，将数据架构尤其是逻辑数据模型放入IT侧的架构设计方法是不太容易做到4个架构充分融合的，因为这是过去谈企业架构时常见的IT设计方法，也是系统分析常用的方法，也是多年来一直没能做好架构融合的设计方法，尤其是在面对大规模跨系统架构体系梳理的时候，单系统范围的梳理有时还看不出问题。业务架构分析中要覆盖逻辑数据模型，而不是只看业务指标、单证书表，这些虽然有助于澄清业务，但还不足以分析结构，是表象的视角，不是对象的视角。这一阶段也不要总把功能分析挂在嘴边，不然分析的实际上可能是应用架构，有些时候大家画的业务架构图看不出和应用架构图的区别，就是因为功能视角潜藏在你的分析思路中，而不是对象和能力的分析，表面上两者看着有些像，实际上，后者分析的是业务的内在，前者分析的只是实现方法，可以有多个前者对应同一个后者，设计上或者说观察上是要找内在。

说到这里，如果严谨些的话，这个图还要更“难看”些才对：

至于为啥要长得“难看”些，读者可以自己思考下。

二、业务架构和企业战略的关系

从上边的关系可以看到，完整的企业架构就是数字企业的完整视图，既然如此，也就可以用来分析企业战略的落地实现了，这里要注意，企业架构承担的职责是寻找企业战略的落地路径。

有些文章会将业务架构理解为单纯基于企业战略设计的，这样说也并非完全不正确，但是还要再精确些，单纯基于企业战略设计的业务架构只有在最严格的条件下才成立，也就是说，这是逻辑上的认识，这个“最严格的条件”指的是，全新的战略、从零做起的企业，一切都是新的，这时才能完全基于战略进行业务架构设计，绝大多数企业都会面临“遗留”问题，“遗留”的组织、“遗留”的业务、“遗留”的系统、“遗留”的数据、“遗留”的人等等，就算大家都很推崇的互联网企业管理风格，也没法把自己清得一干二净从头来，所以，绝大多数时候，企业架构做的是“落差分析”，找的是“落地路径”，也就是从当前架构走到目标架构的实现方法，而目标架构一般也不是凭空出现的，它是基于实现战略产生的“能力”诉求来的，看这个能力需要对现状做出什么样的改变，也就是说，目标架构一开始只是一堆“目标能力”，可能有结构支撑，比如基于价值链分析的“目标能力”，然后开始对现状架构进行逻辑调整，从而产生了目标架构，完全“凌空”的目标架构设计是极其罕见的。

从这个意义上讲，准确地说，业务架构是提供了分析战略实现路径的“基础结构”，不能简单理解为就是通过战略设计业务架构，不要被简单的连线“简单化”了认知。更不能就此将战略实现的分析任务拍给业务架构师，业务架构师可以通过架构资产引导分析过程，但是企业战略是整个企业的战略，不是业务架构师的战略。有架构资产可以使战略实现找到更清晰的路径，尤其是涉及到数字化相关问题时。

笔者非常重视业务架构的作用，但从不因此过于强调业务架构，其实笔者更重视的是蕴含在业务架构中的全局性结构化思维，这是数字时代企业每个员工，上至董事长下至基层一线人员都需要具备的，也只有从业务架构这个点着手，才能让这个思维方式普及到业务侧。不要总想着砍掉基层的“脑袋”，没有符合这个时代的逻辑思维模式，企业就很难在数字时代新质生产力不断快速发展的背景下提升内部沟通效率，笔者之前在《银行数字化转型》一书中专门提出过技术发展的不变趋势是“个体能力持续增强”，而全局性结构化思维正是能力增强的基础，也是“超级个体”们可以有序协作的基础。