业务架构设计的三个核心关注点

[[高速公路”类比：企业战略与业务架构的关系|业务架构]]设计有三个必须守住的核心关注点。第一，关注的是正确的问题，而不是急于寻找正确的答案：应该先思考”我们要解决的问题范围是什么、这些问题与企业战略有何关联、解决它们能给客户带来什么价值、它们在价值流中处于什么位置”，把资源投入到正确的地方远比过早纠结”系统该分成多少个应用、具体怎么建”更重要——后者属于后续应用架构该考虑的范畴。第二，业务架构设计应当只关注功能性需求，暂不考虑约束条件（如地域用户使用习惯这类可能影响功能实现的因素），也不该过早去想非功能性需求的技术实现（架构风格、高性能、高可用等）——过早考虑这些会分散注意力，此时应当假设系统就是一个大的单体架构；这么做的理论依据正是[[需求的三层次、三构成，及被忽视的约束条件|系统架构与功能性通常是正交的]]，而非功能性需求才是更多影响架构设计的那一部分，所以在业务架构这个阶段刻意屏蔽掉非功能性需求，能让思路更聚焦。第三，业务架构必须站在企业整体层面而非部门/业务线层面去看——业务架构首先是自顶向下的产物，体现的是企业战略层面的思路，而企业战略必然是从整体性视角制定的；具体表现为定义价值流时要考虑跨组织跨部门的视角、审视业务流程时要用端到端的视角、根据业务流程提炼业务能力时也应首先从整个企业维度分析，而不是先画好某个部门自己的流程图再拼凑。可迁移启发：审查一份业务架构文档，可以直接用这三条对照检验——它有没有先讲清楚”问题”再谈”方案”、有没有在这个阶段就掺进了具体的技术选型细节、视角是不是局限在了某个部门而非企业整体——任何一条不满足，这份文档很可能不是真正意义上的业务架构，而只是某个部门的流程梳理。