建模方法选型看能否补足业务友好性缺陷以及旧模型成果是否还值得复用

业务架构要同时服务业务和技术两拨受众，但市面上常见的建模方法 在这两端的友好度并不对称。ISO 9000质量体系里的流程模型对业务 人员很友好，但表达能力偏单一，用在软件设计领域会显得对技术 分析支撑不足；UML作为技术人员最熟悉的建模语言，表达能力强、 体系完整（涵盖用例图这类功能模型、类图/对象图这类对象模型、 序列图/活动图/状态图这类动态模型），但对业务人员非常不友好； BPMN则试图在两端之间搭桥，用一套业务用户也容易理解的符号， 覆盖从流程建模一路延伸到面向IT执行语言的完整链路，填补了业务 流程设计和流程开发之间原本的空白。既然业务架构的任务是搭建 业务和技术之间的桥梁，选建模方法时天然应该偏向那些”表达能力 丰富、又兼具业务和技术友好性”的方法。但如果企业已经在原有 技术实现里习惯了某种建模方法，是否值得为了业务架构专门换一套 方法，作者给出两条判断依据：第一，看原有方法能不能被改造弥补 缺陷——如果原方法太偏技术端，能不能给它加上面向业务端的合适 展现方式，如果试验或评估下来效果不理想，那就该考虑换方法； 第二，看原有的模型成果还有没有复用价值——如果企业决心做大 规模转型，原有模型成果除了给前期分析提供一点参考信息之外， 基本没有太大复用空间，这种情况下换建模方法也没什么心理负担。