软件的业务架构（Business Architecture, BA）是个较新的词，可以说是（需要软件化的）业务逐渐复杂的结果。业务复杂到一定规模后，必须对其进行梳理与设计，结果就是BA。
BA通常的工作就是：识别模块、划分功能、厘定（他们间）关系。
一、模块结构图
复杂的系统，通常用模块结构图来表达顶层架构。
上面的例子说明了将构建系统将由3个子系统组成，并与二个已有的外部系统打交道。
二、细化的模块结构图（带接口）
上面的例子比较复杂，我们有必要作出小小的细化，来说明子系统间如何连接。
我们在开发软件时，对于接口，比较模块化的处理方式是将2个系统间接口处理部分逻辑上独立出来，形成Caller与Callee。
做业务架构，可以采取同样的方式。在上图中，多处连接我使用用Service与Adapter来表达Callee与Caller。这种一致化的表达，可以在未来，直接映射到软件逻辑架构。
三、功能分布表（Feature Distribution Table）
通常的业务分析结果，是得到一个功能列表（Feature List）。
但是对于一个大型系统，功能(Feature)将会非常多；并且可能有一定的传递性（即某功能F可能在模块M1、M2、M3中都有体现）。此时使用
功能分布表可能更利于：
》功能识别的完整性
》识别出可重用功能
》分析功能转移的可行性（功能从模块A移到模块B）
下面是针对上述模块结构图的一个示例：
本文转自DavyYew 51CTO博客，原文链接：http://blog.51cto.com/davyyew/241245
，如需转载请自行联系原作者
