要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
TOGAF:从业务架构到业务需求
 

作者:周 金根,发布于2013-1-14,来源:博客园

 

做管理型软件产品一般都要经历架构阶段,而架构又可以简单分为业务架构和技术架构,对于架构方法,在我以前的blog中大量的介绍了TOGAF。

使用TOGAF的几个初衷

在我们开发软件时,如果你做过设计和架构工作,那么你会发现软件开发过程中其实存在很多断沟。

1.业务架构到技术架构的不一致

1.业务架构是一拨人做,技术架构师另一拨人做,结果做业务架构时缺少技术架构的考虑,而技术架构缺少服务于业务的意识,最终没有为业务服务。弄到最后业务架构和技术架构并不能很好的结合起来,导致还需要很多适配或反复工作。

2.还有一种情况是,业务架构做完之后扔给技术架构来实现,但是业务架构提供的东西并不全面,不能提供技术架构的输入,导致沟通效率极其低下。

2.业务架构到业务需求的不一致

1.有些公司虽然岗位分的清楚,但是方法并不清楚。业务架构是一套方法,需求分析是一套方法,甚至于没有方法,而是靠着个人能力去做,结果导致架构和需求交付物是独立的,业务架构的东西不能顺利转移到需求阶段

2.还有时候一个人就负责产品的业务,架构和需求一起做,这时候没有方法的指导,其实很容易迷失在业务细节。 过早的进入业务细节对于产品来说是及其危害的,因为产品架构还未明晰时进入细节只会浪费时间导致重心偏离方向。

3.业务架构和实现的不一致

1.业务架构采用的是业务语言,而技术实现采用的技术语言,两者不是同一个语言,很难做到顺利过渡,还需要再一次翻译,有时候甚至在实现阶段根本不看业务架构出来的东西

2.很少有开发人员清楚产品的业务架构,那么如何能够做出好的产品来?

4.开发产品时,开发问一句,"做这个对系统有什么价值?"结果发现需求根本无法追溯回系统的价值点上,有时连需求人员都不知道为什么做了这个功能。如果产品生命周期较长,中间换了好几拨人来做这个产品了,那么不仅是需求文档不能追溯,就是靠口头讲也讲不清。

从上面可以看书,现实中产品开发存在的隐性问题其实还是蛮多并且很严重的,我也都经历过。而解决这些问题就必须做到一下几点:

1.找到一个指导业务架构的方法和框架

2.结构化架构交付物才有可能把架构知识转移到开发环节

3.必须有一个业务开发平台来集成业务架构、技术架构和开发框架

业务架构和业务需求

TOGAF并没有太多内容来描述如何做业务需求,但是这是我们必须要做的事情。从上面的阐述能够发现,我是希望业务架构和业务需求能够有一种方法进行衔接的。其实业务架构和业务需求本身就不冲突,两者只是处在一个事物在不同层次的东西。架构关注的是更全面、概括、组织方面的东西,而需求关注的是用户关心的业务细节,业务需求是业务架构的进一步分析。

在研发峰会上我讲过一次使用TOGAF来做业务架构,下面是裁剪后的轻型迭代流程和交付物。其中的设计开发步骤中有Backlog,这个就是从业务架构和业务需求的产物。

在我写的敏捷方法之Scrum.pdf电子书中提到产品backlog是在项目开始的时候,由Product Owner准备的一个根据商业价值排好序的客户需求列表。而在我们工作中,这个产品backlog如果要做到承上启下的作用,考虑到它来自于业务架构,而又服务于产品开发,所以我们会定义一些格式,例如考虑功能的抽象、721的分析以及与开发框架匹配的文档组织格式等。

以下的文档是根据我所做业务以及实现框架而做的格式,你可能需要根据你们自己的情况来制定属于自己的backlog格式。

制定Backlog的考虑点

1.由于流程可以动态变化,以静态的功能分解和信息结构作为backlog的主要输入

2.考虑软件产品线工程,进入开发前,设计产品的721

3.结合业务框架的模型抽取来编写业务实体以及功能

4.尽量结构化文档,不采用纯文字描述,逐步抽取出具有确定含义的文字

5.术语和规则作为sprint文档之外的重要文档

产品业务模块backlog

以下是实际工作中的一个示例:

  • 按照子系统、业务模块来组织产品backlog
  • 每个子系统和模块都附上唯一的编号,文档中任何地方都可以引用
  • 输入、输出表达模块之间的关系,这个从业务架构的流程、功能分解中输入
  • 执行者和目的对应业务架构的角色和价值点
  • 范围、工具和技术属于业务需求内容
  • 7/2/1是根据业务、市场来划分此模块是通用功能、可变功能还是定制功能

产品模块功能backlog

产品业务模块backlog大部分内容除了7/2/1之外,大部分内容只是业务架构的另一种表现形式而已。到了需求阶段,必须对产品业务模块backlog进行细化工作,那就是产品模块功能backlog:

  • 按照业务模块、功能点来组织模块功能backlog
  • 抽取公共业务功能、通用业务规则,例如列表模板、通用编辑方式、通用业务功能,这些通用规则和说明形成单独文档,作为技术架构的输入
  • 业务规则列链接具体的业务规则说,业务规则的写法根据遇到的规则类型定义自己的结构化格式
  • 功能点仍旧也要做721设计
  • 对于非通用性的业务功能需要描述具体任务操作步骤以及价值点
  • 加入关注的非功能性需求,我们现在只加入了效率
  • 大多数情况下,这个文档的模块能够对应到开发中的实体,功能点能够对应到界面上的一个按钮或右键等,这样有利于以后转向模型驱动平台下使用设计器来进行产品开发

术语表

如果术语很多,可以进行分组编号

规则表

业务规则对系统来说是核心内容,这部分内容必须仔细查看。规则分析得是否正确、完整是系统实现的前提,每个业务需求通过抽取应该能够形成一些通性规则,对于通行规则可以作为技术框架的输入,由框架统一实现

一些问题

业务架构需要做到什么粒度?

架构是产品的上层框架,只需要到具体功能模块以及主要业务功能就行,具体的业务规则和异常处理都不需要考虑,那是需求分析的事情

业务架构是否需要做原型?

需要,只是会很粗,并且不在意具体的UE,但是需求阶段的原型应该可以从业务架构阶段的原型中细化下来

有没有统一的规则表模板?

不同业务的规则是不一样,不同小组的设计能力也是不一样,不同平台支持的规则DSL也是不一样的,这个需要根据自己的情况来定义自己的格式,但必须能够把规则描述清楚,做到自己、开发人员和测试人员都能一看就明白

需求阶段需要出以前的详细需求规格说明书吗?

对于内部来说不需要。但是必须要有原型,还有我上面说的几个文档,记住一定要保证同步。


 
分享到
 
 


专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践

相关咨询服务
应用架构设计与构建


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...   
 
 
实录 C语言面向对象
主讲:宋宝华
《Linux设备驱动开发详解》的作者
 
实录 基于Tensorflow进行深度学习
主讲:钱兴会
曾任联想集团大数据平台架构师
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号