软件的业务架构(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)
下面是针对上述模块结构图的一个示例: