之前介绍过, 应用业务架构模型可以快速对新需求进行企业级分析, 那就讲一个实际发生过的例子供大家参考.
以前做企业级项目的时候, 曾经接到一个紧急设计业务架构方案的通知. 由于当时公司还处于企业级转型项目的施工期间, 所有业务需求都要经过业务架构分析, 出具业务架构方案, 再落实到具体项目组. 鉴于当时有 50 多个项目组同时施工, 这样的企业级分析过程是非常必要的.
该需求是与某宝合作的实物贵金属在线销售业务, 当时, 另一家竞争对手与某互联网巨头刚刚合作了此类项目, 受市场形势所迫, 必须快马加鞭, 紧急施工. 所幸业务部门已经连夜写出了业务需求, 需求共计 15 页, 将近 9000 字, 涉及 11 个大的需求项, 要马上根据业务需求文档形成业务架构方案.
需求的主要内容包括: 为客户建立虚拟账户, 用于记录客户买卖交易, 持仓等; 支持使用某宝黄金发送红包 (黄金份额); 红包的账务性处理, 红包资金的支付结算及划转; 支持黄金实物兑换; 支持黄金转赠; 销售数据提取, 报表统计, 实物提取配送数据交互以及相应的核算规则等.
当时公司早已经完成了企业级的业务架构和业务模型建设, 并使用模型驱动企业级开发近四年时间, 工具使用已经没有问题. 公司的企业级业务模型包含上百个组件和数十个大型应用, 其中, 该需求所属的业务领域自己包含十余个应用, 业务活动近三十个, 任务超过一百多个, 涉及多个核心组件及公共类支持组件, 需求牵涉的只是其中一个应用. 在有业务架构和业务模型的情况下, 业务架构人员的工作就是识别新业务流程与原有业务流程的差异, 以判断涉及的模型范围, 包括识别出需要使用的活动, 任务, 涉及的组件, 以及需要新增那些内容, 新增的应该归属给哪个任务和组件, 进而, 应用架构人员会根据分析结果给项目组指派具体承接的需求. 当然, 这不是简单的对号入座, 架构设计最重要的就是理清结构和关系, 要说清楚各部分的具体分工和协作, 给出明确的设计理由, 否则, 项目组会质疑任务分工.
经过对文档的仔细研读, 最终理出了 "签约","产品查询","交易 (含红包)","对账","结算费用" 这几个主要工作流程, 涉及 9 个现有业务组件, 现有业务模型基本支持该需求的实现, 部分任务需增加业务规则.
业务架构关系图如下:
来源: http://www.jianshu.com/p/3c491d7f1602